[OpenSIPS-Users] Sqlops in opensips ?

[Brett Nemeroff]

Alex,I whole-heartedly agree with you here. I've seen a number of times that
a slow DB query block worker threads and painfully holds up call processing.
I think this is an inherent danger in interacting with the database in
real-time. avp_db_query allows for this, and this allows for some sloppy
programatic design. I also agree that the core of opensips would be well
served by having a better architecture to deal with this kind of interaction
to gracefully handle blocking scenarios.

As it is right now, I believe if you use the DB API with a custom module,
you still face the same challenges with not having POSIX threads and
blocking queries. Right? It's not perfect, but I'm hoping that memcache can
help with a lot of these needs. I'd like to see delayed ACC writes sometime
as well..
-Brett



On Tue, May 26, 2009 at 6:38 PM, Alex Balashov <abalashov at evaristesys.com>wrote:

> Brett Nemeroff wrote:
>
>  The original intent was to be a fast, scalable SIP router. Having runtime
>> queries against your database didn't fit into that model. Not only that
>> there were no variables. So there was no way to manipulate or otherwise
>> really use the resultant data.
>>
>
> Sure.  But there is a limit to what can be done to meet
> application-specific needs within the box of the existing modules provided.
>  Along with the UAS features that co-evolved onto the proxy layer, the
> increasing generalisation of the pseudoprogrammatic route script environment
> is a logical direction.
>
>  I agree that this stuffed into the AVP module seems odd, but given the AVP
>> module gives the scripting language it's variable capabilities, it makes
>> sense.
>>
>
> I wouldn't dispute that;  on the one hand, it is an odd place to put the
> database interaction functionality, but on the other hand, it is probably
> the most conceptually self-evident place of the existing module library.
>
> I think the ideal answer is C, though - none of the above, make a special
> module for it.
>
>  Before AVPs, you did routing based on module logic and there wasn't anyway
>> to customize it without writing your own modules by hand. As much odd as the
>> avpops module integrates arbitrary database interactions, I'm not sure how
>> I'd change it rather than a typical kind of prepare / execute/ fetch kind of
>> loop. But that isn't an efficient design for a real-time switch. I rather
>> like how it is today.
>>
>
> It does pose a formidable design challenge;  there's not a lot of
> usefulness in "asynchronous" database calls because it's no good - the
> response from the database is still needed to carry on processing a request,
> and that can only happen if the process blocks on database response.
>
> What I think is in dire need of more asynchronous-minded renovation is the
> fact that database calls can block an entire worker process.  Since there
> are no threads used (that is to say, POSIX threads), a spuriously latent
> database operation will block a whole child process.  Child processes handle
> many requests concurrently in a high-volume scenario. So, that needs to
> change.
>
> --
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (678) 237-1775
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090526/664d9384/attachment-0001.htm