[OpenSIPS-Devel] Problem found while testing dialog profile
Vlad Paiu
vladpaiu at opensips.org
Tue Feb 5 15:29:24 CET 2013
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 Developer
http://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 Developer
> http://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 <mailto: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 <mailto: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 list
>> Devel at lists.opensips.org
>> http://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/3962a586/attachment-0001.htm>
More information about the Devel
mailing list