29 jan 2013 kl. 12:16 skrev Peter Dunkley <[email protected]>:
> 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 <[email protected]>: >> >>> 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 >>>> [email protected] >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> >>> -- >>> Peter Dunkley >>> Technical Director >>> Crocodile RCS Ltd >>> _______________________________________________ >>> sr-dev mailing list >>> [email protected] >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >> _______________________________________________ >> sr-dev mailing list >> [email protected] >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
