<div dir="ltr"><div>OK thanks Peter for the clarity. I'll revert to non-notifier for the time being.<br><br></div><div>I will have some interest in multi-server soon so I'll take a look at the PostgreSQL then.<br>
</div><div><br></div>Cheers<br>Shane<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 12:20 PM, Peter Dunkley <span dir="ltr"><<a href="mailto:peter.dunkley@crocodile-rcs.com" target="_blank">peter.dunkley@crocodile-rcs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In DB mode 1 a completely different code path - without notifier processes - is run.<br><br>As I mentioned you only need the notifier processes for resilient multi-server systems. For single server the default presence behaviour without notifier is fine - and multi-server resilient presence will not work in 3.3 anyway (you need git master with PostgreSQL DB for this).<div class="im HOEnZb">
<br><br>Regards,<br><br>Peter<br><br>Shane Harrison <<a href="mailto:shane.harrison@paragon.co.nz" target="_blank">shane.harrison@paragon.co.nz</a>> wrote:<br><br></div><div class="im HOEnZb"><div dir="ltr"><div>Thanks Peter. Note I have repeated your answer below in this correctly titled thread since I accidently hijacked a thread with my original post.</div>
<div> </div><div>I take your point on race conditions. But this doesn't feel like a race condition. It is pretty predictable. Basically if the "updated" column is set to an odd number then process_dialogs() never processes that database notify entry.</div>
<div> </div><div>This only happens in db-mode 2 (database only). In db-mode 1 the notifies are handled immediately and we never see this issue. At least that is my conclusion from observations.</div><div> </div><div>Cheers</div>
<div>Shane</div><div> </div><div> </div><div> </div><div>Peter Dunkley wrote</div><div> </div><div>--------------------------------------------</div><div>Hello,<br><br>The polled notification stuff in 3.3.3 has some issues. There are some database related race-hazards that mean you could have problems. These have been resolved by adding new features to the database library - but as these are new features they are only present in git master at the moment. The presence modules in git master have been updated to use these new features.<br>
<br>It is also worth noting that the PostgreSQL database driver in git master is significantly more advanced, in terms of features, than the other database drivers. The presence notifier stuff has only been tested with PostgreSQL and may well be totally dependent on features that are only in the driver for that database (it should still run without crashing when using other databases but will probably not function correctly). When you do your retest please make sure that you use PostgreSQL - if you must use another database then you will need to update the Kamailio driver for that database to include support for the following new APIs:</div>
<ul><li>init2 </li><li>start_transaction </li><li>end_transaction </li><li>abort_transaction </li><li>query_lock</li></ul><div><br>Please retry with git master and PostgreSQL and let me know if the problem persists.<br>
<br>Regards,<br><br>Peter<br></div><div>----------------------------------------------------</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 9:17 AM, Shane Harrison <span dir="ltr"><<a href="mailto:shane.harrison@paragon.co.nz" target="_blank">shane.harrison@paragon.co.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">Hi all,<br><div dir="ltr"><div>I have a situation where subscriptions do not get notified and have tracked it down to a problem with the polled notify processing. Can you advise if this is a bug or correct my understanding of the code.<div>
<br></div></div><div>I am using kamailio 3.3.3 and have 1 notify process. I have enhanced the support for the ua-profile event (rfc 6080) , although I don't believe I have made any changes that directly impact the problem I am seeing. </div>
<div>
<div> </div><div>When a new subscription arrives it is added to the active_watchers table, the 'updated' column is assigned a number in the range 0 - N-1, where N is effectively the total number of polled update tasks that are called in a round-robin fashion, distributed across the notify processes. In this case updated = 7.</div>
<div><br></div></div><div><div>In subscribe.c:</div><div><div>int update_subscription_notifier(struct sip_msg* msg, subs_t* subs,<span style="white-space:pre-wrap"> </span>int to_tag_gen, int* sent_reply)</div>
<div>{</div><div><span style="white-space:pre-wrap">...</span></div>
<div><span style="white-space:pre-wrap"> </span>/* Set the notifier/update fields for the subscription */</div><div><span style="white-space:pre-wrap"> </span>subs->updated = core_hash(&subs->callid, &subs->from_tag, 0) %</div>
<div><span style="white-space:pre-wrap"> </span>(pres_waitn_time * pres_notifier_poll_rate</div><div><span style="white-space:pre-wrap"> </span>* pres_notifier_processes);</div><div><br></div></div></div><div>
<div>
The notify process periodically calls pres_timer_send_notify(), which calculates the round (the update task number) and does the notify update by checking the active_watchers table for entries with updated = round. The update is done twice, first for the event then for event.winfo.</div>
<div><br></div></div><div><div>In notify.c:</div><div><div>void pres_timer_send_notify(unsigned int ticks, void *param)</div><div>{</div><div><span style="white-space:pre-wrap"> </span>int process_num = *((int *) param);</div>
<div>
<span style="white-space:pre-wrap"> </span>int round = subset + (pres_waitn_time * pres_notifier_poll_rate</div>
<div><span style="white-space:pre-wrap"> </span>* process_num);</div><div><span style="white-space:pre-wrap"> </span>if (process_dialogs(round, 0) < 0)</div><div><span style="white-space:pre-wrap"> </span>{</div>
<div><span style="white-space:pre-wrap"> </span>LM_ERR("Handling non presence.winfo dialogs\n");</div><div><span style="white-space:pre-wrap"> </span>return;</div><div><span style="white-space:pre-wrap"> </span>}</div>
<div><span style="white-space:pre-wrap"> </span>if (process_dialogs(round, 1) < 0)</div><div><span style="white-space:pre-wrap"> </span>{</div><div><span style="white-space:pre-wrap"> </span>LM_ERR("Handling presence.winfo dialogs\n");</div>
<div><span style="white-space:pre-wrap"> </span>return;</div><div><span style="white-space:pre-wrap"> </span>}</div><div>}</div><div><br></div></div><div>In this instance process_num = 0, so round = subset. However subset is incremented in process_dialogs() in notify.c:</div>
<div>
<div><br></div><div><div><span style="white-space:pre-wrap"> </span>if (++subset > (pres_waitn_time * pres_notifier_poll_rate) -1)</div><div><span style="white-space:pre-wrap"> </span>subset = 0;</div>
<div><br></div><div>This means that round is incremented twice between calls to process_dialogs(round, 0), in my case round is always even, hence not detecting the subscription with updated = 7.</div><div><br>
</div><div>It seems that the subset increment should be done in pres_timer_send_notify() rather than in process_dialogs(). Is this correct?</div><div><br></div><div>Additionally, is there a need for the second call that only handles presence.winfo subscriptions? The code could be simplified by only making one call and processing all subscriptions for the round.</div>
</div></div></div></div>
</div><div> </div><div>Kind regards</div><span><font color="#888888"><div>Shane Harrison<br><br clear="all"><br>-- <br></div><div>Imagination NZ Ltd<br>Level 6 </div>
<div>92 Queens Drive<br>P0 Box 30449<br>Lower Hutt 5040<br><br>+64 4 5703870 Extn 875<br>+64 21 608919 (mobile)<br></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div>Imagination NZ Ltd<br>Level 6 </div>
<div>92 Queens Drive<br>P0 Box 30449<br>Lower Hutt 5040<br><br>+64 4 5703870 Extn 875<br>+64 21 608919 (mobile)<br></div>
</div>
</div></div><br>_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div>Imagination NZ Ltd<br>Level 6 </div>
<div>92 Queens Drive<br>P0 Box 30449<br>Lower Hutt 5040<br><br>+64 4 5703870 Extn 875<br>+64 21 608919 (mobile)<br></div>
</div>