<div><br><div><br></div><div><br><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 12:18 PM, Vlad Paiu <span dir="ltr"><<a href="mailto:vladpaiu@opensips.org">vladpaiu@opensips.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff">
<div style="font-family:-moz-fixed;font-size:12px" lang="x-western">Hello
all,
<br>
<br>
Problem :
<br>1) Extend the OpenSIPS DB core. Add extra core processes that would
only handle queries that return no results. <br>
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.
<br><br></div></div></blockquote><div><br></div><meta charset="utf-8">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.<div>
<br></div><div>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?<br><br></div><div>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*</div>
<div><br></div><div>-Brett</div><div><br></div><div><br></div><div> </div></div></div></div>