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 <[email protected]>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 >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
