Alex,<div>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. </div>
<div><br></div><div>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..</div>
<div>-Brett</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, May 26, 2009 at 6:38 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Brett Nemeroff wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br>
</blockquote>
<br></div>
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.<br>
<br>
I think the ideal answer is C, though - none of the above, make a special module for it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<font color="#888888">
<br>
-- <br></font><div><div></div><div class="h5">
Alex Balashov<br>
Evariste Systems<br>
Web : <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
Tel : (+1) (678) 954-0670<br>
Direct : (+1) (678) 954-0671<br>
Mobile : (+1) (678) 237-1775<br>
</div></div></blockquote></div><br></div>