<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 18, 2013 at 12:58 AM, Tilghman Lesher <span dir="ltr"><<a href="mailto:tilghman@meg.abyt.es" target="_blank">tilghman@meg.abyt.es</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">On Sun, Nov 17, 2013 at 3:31 PM, Damon Estep <<a href="mailto:damon@soho-systems.com">damon@soho-systems.com</a>> wrote:<br>

>> ><br>
>> >> If you really are averse to the effect that saving lastms in the<br>
>> >> database causes, why don't you just remove that column from your<br>
>> >> realtime tables?  We've had this ability to remove columns that you<br>
>> >> prefer not to save in dynamic realtime since 1.6.2, and it sounds<br>
>> >> like this is, in effect, precisely what you'd prefer.<br>
>> >><br>
>> >> -Tilghman<br>
>> >><br>
>> ><br>
>> > Can you help me understand what removing the column would do? I did not<br>
>> see anything in the code that would stop the database update attempt if the<br>
>> column did not exists. Would it not try, or would it just fail gracefully?<br>
>><br>
>> The meta-code would simply drop that column from the UPDATE, if it doesn't<br>
>> exist in the target table.<br>
><br>
> Are we talking about something implemented in realtime_odbc, or also in realtime_mysql?<br>
> And if it is the only column in the update, as in the case of a peer state change update?<br>
> The generated update query on peer state change is 'update sipusers set lastms = [value] where name = [peername]'<br>
<br>
</div>It's implemented in both the ODBC and the MySQL realtime drivers.  In<br>
both cases, however, the first key/value pair should always exist and<br>
if it doesn't, both will fail:  the MySQL driver will emit an ERROR,<br>
and the ODBC driver will attempt to execute what will be invalid SQL.<br>
This is clearly a bug in the ODBC driver.  This situation probably<br>
could be fixed in the realtime drivers to simply short-circuit and<br>
cancel out the operation when no columns can be updated.<br>
<div class="im"><br>
> BTW, thanks for taking the time to discuss this.<br>
<br>
</div>I still think the better option would be to control the rate at which<br>
probes for peers are sent out, so their responses can be received and<br>
processed on time.  Either of these present solutions are merely<br>
attempting to code to the symptom, rather than fixing this underlying<br>
problem.  However, moving the probes from the individual peer threads<br>
to a single background thread is not an easy or simple change, which<br>
is probably why you haven't attempted it.<br></blockquote><div><br></div><div style>I agree with Tilghman. The correct way of handling this would be to either offload the database queries to a separate thread, or multi-thread the entire system such that a blocking call to the database does not impact other request handling. This is exceptionally non-trivial to accomplish in chan_sip, as it has no concept of asynchronous callbacks and resuming operations.</div>
<div style><br></div><div style>This is a large part of why we went with a new architecture in the PJSIP stack, which doesn't suffer from this particular limitation (a thread pool is used for request/response handling, so responses that take significant time to process do not impact the handling of other responses). I understand that waiting for Asterisk 12/13 may not be an option and may require you to attempt to solve this in chan_sip; however, I have a feeling that such an effort would be an exceptionally difficult project.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>