29 Jan
2013
29 Jan
'13
1:16 p.m.
Hi Olle,
It was all documented in the commit comments :-)
It has also been mentioned on the mailing lists on more than one
occasion.
On a more serious note, all that is required to make this work properly
in MySQL is for someone to spend a few hours implementing MySQL versions
of the new PostgreSQL functions (transaction handling, locking, etc
differs between databases so what is needed is a MySQL version of the
PostgreSQL functions rather than just copying them into the MySQL
driver). I offered to help anyone who wanted to do this at the time but
was not prepared to do it all myself (I don't use MySQL, don't have it
installed anywhere, don't know how to use it) - but nobody volunteered.
I'd far rather someone just updated the MySQL database driver than
editing the documentation to say what it doesn't do. I don't have any
plans to update the MySQL documentation for this as, to be honest,
no-one would find it there. If it must go anywhere then the
documentation for the presence, pua, and rls would be the best place
(best but not good, the READMEs for these are already complex and I
suspect this would confuse matters further - best thing would be for
someone who uses and can test MySQL to update the MySQL driver).
Regards,
Peter
On Tue, 2013-01-29 at 11:55 +0100, Olle E. Johansson wrote:
29 jan 2013 kl. 11:48 skrev Peter Dunkley
<peter.dunkley(a)crocodile-rcs.com>om>:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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.
Peter - is this documented in any README?
Anyone that can take a look at the mySQL database driver?
/O
Regards,
Peter
On Tue, 2013-01-29 at 13:32 +1300, Shane Harrison wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 