Module: sip-router Branch: master Commit: ebe16f75b38c76dab141ca9583b10b67e4f45f57 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ebe16f75...
Author: Alex Hermann alex@speakup.nl Committer: Alex Hermann alex@speakup.nl Date: Mon Jan 28 13:06:08 2013 +0100
lib/srdb1: Fix compilation warning on 32-bit architectures
On "bits-challenged" architectures, long != 64 bits. Use long long instead, seems to work on 64-bit archs too.
---
lib/srdb1/db_ut.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/srdb1/db_ut.c b/lib/srdb1/db_ut.c index 9942cdc..c57ef4d 100644 --- a/lib/srdb1/db_ut.c +++ b/lib/srdb1/db_ut.c @@ -465,7 +465,7 @@ int db_val2pv_spec(struct sip_msg* msg, db_val_t *dbval, pv_spec_t *pvs) db_longlong2str(dbval->val.ll_val, ll_buf, &pv.rs.len); pv.rs.s = ll_buf; /* if it fits, also store as 32 bit integer*/ - if (! ((unsigned long)dbval->val.ll_val & 0xffffffff00000000)) { + if (! ((unsigned long long)dbval->val.ll_val & 0xffffffff00000000ULL)) { pv.flags |= PV_VAL_INT | PV_TYPE_INT; pv.ri = (int)dbval->val.ll_val; }
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
On Tuesday 29 January 2013 01:32:22 Shane Harrison wrote:
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 don't see how this could have anything to do with my fix, could you elaborate on that please?
Sorry everyone, feel like a bit of a noob! I must have used reply on this thread to post my new thread post and didn't change the subject. So Alex, my issue has nothing to do with your fixes :-)
I have re-reposted my question on a new thread.
Once again, apologies for the confusion.
Kind regards Shane
On Tue, Jan 29, 2013 at 9:46 PM, Alex Hermann alex@speakup.nl wrote:
On Tuesday 29 January 2013 01:32:22 Shane Harrison wrote:
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 don't see how this could have anything to do with my fix, could you elaborate on that please? -- Alex Hermann
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
29 jan 2013 kl. 11:48 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
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:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@crocodile-rcs.com:
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:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
29 jan 2013 kl. 12:16 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
Hi Olle,
It was all documented in the commit comments <face-smile.png>
It has also been mentioned on the mailing lists on more than one occasion.
That doesn't really answer my question, and you know it :-)
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 think this has to be done before release. I see it as a bug fix...
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).
Ok, but that the documention is complex is another problem to sort out. It doesn't give you a green card not to document important things :-)
I'll see if I can wrap my head around the MySQL driver unless someone with more skills in MySQL development takes on this task.
/O
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@crocodile-rcs.com:
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:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Olle,
I understand your point, but the PostgreSQL change was made many months ago. It would have been premature to update the documentation at that point given that I fully expected someone would want to use MySQL with presence and would have made the changes before the next major release.
As I said this was mentioned on the lists at the time, so there was ample opportunity.
Incidentally, the previous (pre notifier process) presence behaviour (which does contain various bugs and race-hazards of its own) is still present in the presence modules and is the default mode of operation. The new code which requires the new database procedures is only used if you explicitly enable it through modparams. The fact that this new behaviour is disabled by default is clear from the documentation
Regards,
Peter
On Tue, 2013-01-29 at 13:32 +0100, Olle E. Johansson wrote:
29 jan 2013 kl. 12:16 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
Hi Olle,
It was all documented in the commit comments <face-smile.png>
It has also been mentioned on the mailing lists on more than one occasion.
That doesn't really answer my question, and you know it :-)
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 think this has to be done before release. I see it as a bug fix...
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).
Ok, but that the documention is complex is another problem to sort out. It doesn't give you a green card not to document important things :-)
I'll see if I can wrap my head around the MySQL driver unless someone with more skills in MySQL development takes on this task.
/O
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@crocodile-rcs.com:
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:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Alex Hermann -
Olle E. Johansson -
Peter Dunkley -
Shane Harrison