[OpenSIPS-Users] Proposed change to cachedb

Brett Nemeroff brett at nemeroff.com
Wed Jul 23 16:44:08 CEST 2014


Hey Vlad,
That's great to hear. I'm using an older version right now.. I think it's
1.9 based. I can't upgrade quite yet. Is there a way to back port the
changes to 1.9?

Thanks,
Brett



On Wed, Jul 23, 2014 at 9:32 AM, Vlad Paiu <vladpaiu at opensips.org> wrote:

>  Hello Brett,
>
> What OpenSIPS version are you using ?
>
> In the latest GIT for all maintained branches, the code was fixed to
> propagate the exact return from the module implementing the module
> connectivity, except for the 0 return code, which is converted to 1 (
> success ) - done in order not to break the script execution.
>
> Best Regards,
>
> Vlad Paiu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 23.07.2014 17:18, Brett Nemeroff wrote:
>
> Hey All,
>
>  Using memcached..
>
>  So I've noticed that while performing a cache_fetch I can't tell the
> difference between a cache failure and a NOT_FOUND. It seems the problem is
> actually in cachedb.c because we do this at the end of cachedb_fetch:
>
>      return cde->cdb_func.get(con,attr,val)<0?-1:1;
>
>
>  So I read this to basically say to return -1 on any failure regardless
> of the failure code. This is probably because of the generalized nature of
> the cache interface and since each cache backend has it's own return codes.
> I get that, but that being said, I can't tell what the failure is and
> respond properly.
>
>  So I changed that one return line to look more like this:
>
>          res = cde->cdb_func.get(con,attr,val);
>         if (res < 0) {
>           return res;
>         } else {
>           return 1;
>         }
>
>  Is this acceptable? Will I run into problems I'm not thinking about? The
> only real problem I can see is that a specific error number on one cache
> backend might mean something different on another. Obviously the only way
> to really fix this would be to have each cache backend to match up it's own
> backend's reply codes to a set of generic opensips cache engine reply codes
> separately enumerated.
>
>  Thoughts?
>
>  Thanks,
> Brett
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140723/8d29a2c9/attachment.htm>


More information about the Users mailing list