[OpenSIPS-Devel] Problem found while testing dialog profile

[Julien Chavanton]

Excellent, thank you for the feedback

On Tue, Feb 5, 2013 at 3:29 PM, Vlad Paiu <vladpaiu at opensips.org> wrote:

> **
> Hi Julien,
>
> I've successfully replicated the issue, and it seems the issue is that
> there's a memcached 'bug', so that when you try to fetch the counter as a
> string,it returns the length as being the biggest number of digits that the
> counter has ever had.
>
> In OpenSIPS 1.9 and trunk, the fix was fairly straight-forwards, since in
> the CacheDB interface there is a separate function that should be using
> when fetching a counter, so the mitigation for this memcached issue was
> done in the cachedb_memcached module.
>
> In OpenSIPS 1.8, we had a single function responsible for fetching keys &
> counters, and thus I fixed this issue my right&left trimming spaces in the
> dialog module when fetching what we expect to be a counter.
>
>
> Regards,
>
> Vlad Paiu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
>
> On 02/05/2013 02:08 PM, Vlad Paiu wrote:
>
> Hello Julien,
>
> This bug seems to have fallen through the cracks while we were preparing
> for the release, so sorry for this.
> Next time, for bug reporting, could you please use the SF tracker ?
>
> About the actual bug, not sure if I entirely get your last message's
> point, and how would incrementing by 0 help solve the issue ?
> As far as I understand, the issue appears when you get more than 10
> dialogs ongoing and you try to get the profile size ?
>
> I will try to replicate this locally, but I'd appreciate a little bit more
> details about the issue.
>
> Best Regards,
>
> Vlad Paiu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
>
> On 01/14/2013 01:46 PM, Julien Chavanton wrote:
>
> One option would be to increment by 0 using a memcached_increment and use
> the return value, this way we keep the atomic feature provided by memcached.
>
> However this would break the cachedb abstraction since we would not use a
> normal "cdb_func.get" but a cdb_func.add "0"
>
> dialog profile -get-> | cachedb |  memcached
>
> Cachedb specific feature like increment may not be easily abstracted.
>
>
>
>
>
> On Mon, Jan 14, 2013 at 11:52 AM, Julien Chavanton <jchavanton at gmail.com>wrote:
>
>> I found out that the problem is taking place in memcached, once the size
>> of a value is not lowered when decrementing.
>>
>> This is what we have int memcached after having reached a dialog profile
>> of a number with more then 2 digits (10+)
>>
>> # Increment
>> incr dlg_val_caller_ODA1MQ== 1.
>> 1.
>>
>> # Get the value (size 2 !!)
>> get dlg_val_caller_ODA1MQ== .
>> VALUE dlg_val_caller_ODA1MQ== 0 2.
>> 1 .
>> END.
>>
>> # Decrement
>> decr dlg_size_caller 1.
>> 0.
>>
>> ----------------------------------------------------------
>>
>> Then str2int is failing in dlg_profile.c
>>
>>  if (str2int(&ret, &n) < 0) {
>>                         LM_ERR("invalid int value in CacheDB <%.*s>\n",
>>
>>
>>
>>
>>
>> On Mon, Jan 14, 2013 at 10:34 AM, Julien Chavanton <jchavanton at gmail.com>wrote:
>>
>>> Hi, I found a problem that may require more investigation but just in
>>> case I do not look into it further I wanted to raise the issue.
>>>
>>> Problem found while testing dialog profiles :
>>>
>>> ERROR:dialog:get_profile_size: invalid int value in CacheDB <1 >
>>> ERROR:dialog:get_profile_size: invalid int value in CacheDB <0 >
>>>
>>> This problem with the white space as triggered while testing when the
>>> profile get higher then 10 ?
>>>
>>>
>>>
>>
>
> _______________________________________________
> Devel mailing listDevel at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing listDevel at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130205/bd70ca41/attachment.htm>