Hi Dave,
We decided to put the async support in core (the mechanism for "moving"
a query from current process to a DB process) - each DB module will
choose to use or not this async support (like for db_text makes not
sense, db_postgres may have a buitin one, etc)
Regards,
Bogdan
On 03/16/2011 11:26 PM, Dave Singer wrote:
Vlad,
Would it be possible extend DB_VITRUAL kind of a combination of your
two options and Brett's suggestion.
I'm just guessing how things might work and possibilities. So for what
it is worth...
Since it is a middle layer, it could either use the async capabilities
of the native driver or put it in a queue to be handled by a special
db queue process that could also be threaded potentially (if
beneficial). The IPC would only need to pass the query that is needed.
To take advantage of the async the user would only need to use the
DB_VIRTUAL module.
Probably would want a module param to enable/disable async
(async_db_updates) in case it is important and maybe a bit flag option
as well that would reverse the async_db_updates option when flag set
for case by case basis.
Potentially with a separate queue process updates like registrations
could be combined into a single update.
Dave
On Wed, Mar 16, 2011 at 10:32 AM, Brett Nemeroff<[email protected]> wrote:
On Wed, Mar 16, 2011 at 12:18 PM, Vlad Paiu<[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.
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?
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*
-Brett
--
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
