[OpenSIPS-Users] Sqlops in opensips ?

[Alex Balashov]

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