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 < [email protected]> 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 <[email protected]> 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 < > [email protected]> 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 > [email protected] > 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)
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
