Hi Brett,
On 03/16/2011 07:32 PM, Brett Nemeroff wrote:
On Wed, Mar 16, 2011 at 12:18 PM, Vlad Paiu <[email protected]
<mailto:[email protected]>> wrote:
Hello all,
Problem :
1) Extend the OpenSIPS DB core. Add extra core processes that
would only handle queries that return no results.
For example : The accounting module need to insert an entry in
the DB. The module calls the insert() function. Behind the scene,
this triggers passing all the arguments to the new core processes,
via IPC mechanisms. The insert() then exists and the SIP children
continues execution as if the entry has been inserted in the DB.
Meanwhile, the DB core processes receive the new parameters, build
and send the query, blocking if necessary.
Maybe I'm just saying the same thing another way, but what about an
async execution queue. So you basically add to the queue messages to
be executed to the database and on some sort of timer loop process
them. To the script, we just assume everything is 100% successful.
yes, it is the same what Vlad said, but in other words :)
Is IPC really necessary for this? The goal here is really just to
offload the processing elsewhere so that the DB slowness doesn't
adversely affect opensips core performance. right?
IPC is a really generic way of saying - the idea is that you need to
"move" the query from the process handling the SIP message to another
process (DB related only)
I thin it's also important that there is a async execute and a sync
execute and people (users?) need to know that in the async execute,
you won't know if the execute succeeded in the script logic *ever*
this support will be mainly be used from the other SIP modules (by the
internal code) and not from script, so for "users", this will be
transparent.
Regards,
Bogdan
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users