[sr-dev] git:master: lib/srdb1: Fix compilation warning on 32-bit architectures

[Peter Dunkley]

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 Tue, 2013-01-29 at 13:32 +1300, Shane Harrison wrote:
> Hi there,
>  
> 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 extended
> the support for the ua-profile event (rfc 6080). 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(). Does that
> make sense?
> 
> 
> 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.
> 
> 
> Cheers
> 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)
> 
> 
> 
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130129/c15e6e2a/attachment-0001.htm>