[sr-dev] notify process-dialogs() problem

Wed Jan 30 01:37:25 CET 2013

OK thanks Peter for the clarity.  I'll revert to non-notifier for the time
being.

I will have some interest in multi-server soon so I'll take a look at the
PostgreSQL then.

Cheers
Shane

On Wed, Jan 30, 2013 at 12:20 PM, Peter Dunkley <
peter.dunkley at crocodile-rcs.com> wrote:

> In DB mode 1 a completely different code path - without notifier processes
> - is run.
>
> 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).
>
>
> Regards,
>
> Peter
>
> Shane Harrison <shane.harrison at paragon.co.nz> wrote:
>
> Thanks Peter.  Note I have repeated your answer below in this correctly
> titled thread since I accidently hijacked a thread with my original post.
>
> 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.
>
> 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.
>
> Cheers
> Shane
>
>
>
> Peter Dunkley wrote
>
> --------------------------------------------
> Hello,
>
> 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.
>
> 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:
>
>    - init2
>    - start_transaction
>    - end_transaction
>    - abort_transaction
>    - query_lock
>
>
> Please retry with git master and PostgreSQL and let me know if the problem
> persists.
>
> Regards,
>
> Peter
> ----------------------------------------------------
>
>
> On Wed, Jan 30, 2013 at 9:17 AM, Shane Harrison <
> shane.harrison at paragon.co.nz> wrote:
>
>> Hi all,
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> In subscribe.c:
>> int update_subscription_notifier(struct sip_msg* msg, subs_t* subs, int
>> to_tag_gen, int* sent_reply)
>> {
>> ...
>>  /* Set the notifier/update fields for the subscription */
>> subs->updated = core_hash(&subs->callid, &subs->from_tag, 0) %
>>  (pres_waitn_time * pres_notifier_poll_rate
>> * pres_notifier_processes);
>>
>>  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.
>>
>> In notify.c:
>> void pres_timer_send_notify(unsigned int ticks, void *param)
>> {
>> int process_num = *((int *) param);
>>  int round = subset + (pres_waitn_time * pres_notifier_poll_rate
>>  * process_num);
>> if (process_dialogs(round, 0) < 0)
>> {
>>  LM_ERR("Handling non presence.winfo dialogs\n");
>> return;
>> }
>>  if (process_dialogs(round, 1) < 0)
>> {
>> LM_ERR("Handling presence.winfo dialogs\n");
>>  return;
>> }
>> }
>>
>> In this instance process_num = 0, so round = subset. However subset is
>> incremented in process_dialogs() in notify.c:
>>
>> if (++subset > (pres_waitn_time * pres_notifier_poll_rate) -1)
>> subset = 0;
>>
>> 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.
>>
>> It seems that the subset increment should be done in
>> pres_timer_send_notify() rather than in process_dialogs(). Is this correct?
>>
>> 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.
>>
>> Kind regards
>> Shane Harrison
>>
>>
>> --
>> Imagination NZ Ltd
>> Level 6
>> 92 Queens Drive
>> P0 Box 30449
>> Lower Hutt 5040
>>
>> +64 4 5703870 Extn 875
>> +64 21 608919  (mobile)
>>
>
>
>
> --
> Imagination NZ Ltd
> Level 6
> 92 Queens Drive
> P0 Box 30449
> Lower Hutt 5040
>
> +64 4 5703870 Extn 875
> +64 21 608919  (mobile)
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

-- 
Imagination NZ Ltd
Level 6
92 Queens Drive
P0 Box 30449
Lower Hutt 5040

+64 4 5703870 Extn 875
+64 21 608919  (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130130/00c21a8f/attachment.htm>