<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'>>> >> 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]'<o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><br>> BTW, thanks for taking the time to discuss this.<o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Matt<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><div><p class=MsoNormal style='margin-left:.5in'><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>While I agree from a long term perspective, I maintain the position that the value of having the peer state in the RT database is limited to a minority of users. With that behind said, a simple switch to turn off updates to the RT database updates on qualify state change, without affecting default behavior, is a good solution for 1.8. An imperfect solution is better than no solution and nobody is hurt if the default behavior does not change.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>There are a couple factors that keep me from tackling the project of threading the updates, one of which is that I don't know the code well enough and I have limited programming experience, and the other is that I don't rely on the lastms data in any way, so it would be a lot of work for zero benefit. A selfish stance I know, but I still do not understand how realtime lastms data is used in other user's solutions. I only heard from one person that uses it to make routing decisions [Leandro Dardini]. The "right" solution is going to require some additional participation from someone that has a need for the data and a large scale deployment that has been impacted by the issue.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have attached a patch (against 1.8.15.0) that I am using that addresses a few sip scalability and timer issues, this being one of them. The changes are:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>1. Adds a configuration parameter 'rtlastms=yes|no' that can be used to turn off realtime database updates on qualify state change. It also gracefully omits the field lastms from register and expire realtime database updates.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>2. Adds the ability to define the frequency of qualify pokes when a peer is offline at the general and peer level with the use of a parameter qualifynotok=[time in ms].<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>3. Fixes a bug where t1min is enforced on peers with qualify=no. I looked at the history of t1min and it was never intended to impact peers with qualify=no, that is what 'timert1=' is for. I also changed the sanity check on timer t1 to < 50ms.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>4. Fixes a sanity check on timerB.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would submit the patch to the issue tracker, but the feedback here has suggested it would not be merged.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Damon<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div></div></div></div></div></body></html>