I’ve been looking through the presence module and have some questions regarding the DB_ONLY mode of operation.
Specifically the feature seems to rely on data not being written to hash tables in certain areas of the code, as no checking is done to verify which db_mode is being used.
However there are places where the hash table is populated irrelevant of the db_mode, for example the init code calls pres_htable_restore. Additionally update_presentity seems to also manipulate the hash tables indiscriminately.
Am I missing something here, or is this a bug?
Paul
On Tuesday 19 July 2011, Paul Pankhurst wrote:
I’ve been looking through the presence module and have some questions regarding the DB_ONLY mode of operation. Specifically the feature seems to rely on data not being written to hash tables in certain areas of the code, as no checking is done to verify which db_mode is being used. However there are places where the hash table is populated irrelevant of the db_mode, for example the init code calls pres_htable_restore. Additionally update_presentity seems to also manipulate the hash tables indiscriminately. Am I missing something here, or is this a bug?
Hi Paul,
i think a similar question is discussed at the moment in the user list thread:
"xcap server - http load–balancer: xcap authentication problem"
Maybe you can have a look.
Best regards,
Henning
Hello Paul,
All the functions you mentioned deal with the "presentity" table. The pres_htable_restore fills the presentity htable with data from the "presentity" table. Also, update_presentity, doesn't touch the active_wtchers table.
The db_mode flag, is relevant ONLY for active subscriptions. That means, reSUBSCRIBE requests will be matched with the active_watchers table. Also, initial SUBSCRIBE requests will trigger an immediate write to the active_watchers table when in db_only mode (of course, if the rules allow this, else it will go into the watchers table immediately).
In fallback2db mode, the subscriptions are held in the hashtable and periodically written to the active_watchers table.
In the third mode, memory only, the subscriptions are held ONLY in hashtable.
Best regards, Marius
________________________________ From: Henning Westerholt henning.westerholt@1und1.de To: sr-dev@lists.sip-router.org Cc: Paul Pankhurst paul@crocodile-rcs.com Sent: Wednesday, July 20, 2011 2:14 PM Subject: Re: [sr-dev] DB_ONLY mode in presence module
On Tuesday 19 July 2011, Paul Pankhurst wrote:
I’ve been looking through the presence module and have some questions regarding the DB_ONLY mode of operation. Specifically the feature seems to rely on data not being written to hash tables in certain areas of the code, as no checking is done to verify which db_mode is being used. However there are places where the hash table is populated irrelevant of the db_mode, for example the init code calls pres_htable_restore. Additionally update_presentity seems to also manipulate the hash tables indiscriminately. Am I missing something here, or is this a bug?
Hi Paul,
i think a similar question is discussed at the moment in the user list thread:
"xcap server - http load–balancer: xcap authentication problem"
Maybe you can have a look.
Best regards,
Henning
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Thanks for that Henning...seems to agree with some of the things I've seen in the code.
I'm currently modifying all the presence related modules to support a pure DB_ONLY mode.
I'm currently working on pua module, I'll check with Marius before I touch the presence module
Paul
-----Original Message----- From: Henning Westerholt Sent: Wednesday, July 20, 2011 12:14 PM To: sr-dev@lists.sip-router.org Cc: Paul Pankhurst Subject: Re: [sr-dev] DB_ONLY mode in presence module
On Tuesday 19 July 2011, Paul Pankhurst wrote:
I’ve been looking through the presence module and have some questions regarding the DB_ONLY mode of operation. Specifically the feature seems to rely on data not being written to hash tables in certain areas of the code, as no checking is done to verify which db_mode is being used. However there are places where the hash table is populated irrelevant of the db_mode, for example the init code calls pres_htable_restore. Additionally update_presentity seems to also manipulate the hash tables indiscriminately. Am I missing something here, or is this a bug?
Hi Paul,
i think a similar question is discussed at the moment in the user list thread:
"xcap server - http load–balancer: xcap authentication problem"
Maybe you can have a look.
Best regards,
Henning
On Thursday 21 July 2011, Paul Pankhurst wrote:
Thanks for that Henning...seems to agree with some of the things I've seen in the code.
I'm currently modifying all the presence related modules to support a pure DB_ONLY mode.
I'm currently working on pua module, I'll check with Marius before I touch the presence module
Hi Paul,
sounds great, improvements are of course always welcome.
Best regards,
Henning
Hello Paul,
I have already made a patch to the presence module to support a pure DB_ONLY mode (also for presentities). You can check it out on the master branch.
Regards, Marius
________________________________ From: Paul Pankhurst paul@crocodile-rcs.com To: Henning Westerholt henning.westerholt@1und1.de; sr-dev@lists.sip-router.org Sent: Thursday, July 21, 2011 11:24 AM Subject: Re: [sr-dev] DB_ONLY mode in presence module
Thanks for that Henning...seems to agree with some of the things I've seen in the code.
I'm currently modifying all the presence related modules to support a pure DB_ONLY mode.
I'm currently working on pua module, I'll check with Marius before I touch the presence module
Paul
-----Original Message----- From: Henning Westerholt Sent: Wednesday, July 20, 2011 12:14 PM To: sr-dev@lists.sip-router.org Cc: Paul Pankhurst Subject: Re: [sr-dev] DB_ONLY mode in presence module
On Tuesday 19 July 2011, Paul Pankhurst wrote:
I’ve been looking through the presence module and have some questions regarding the DB_ONLY mode of operation. Specifically the feature seems to rely on data not being written to hash tables in certain areas of the code, as no checking is done to verify which db_mode is being used. However there are places where the hash table is populated irrelevant of the db_mode, for example the init code calls pres_htable_restore. Additionally update_presentity seems to also manipulate the hash tables indiscriminately. Am I missing something here, or is this a bug?
Hi Paul,
i think a similar question is discussed at the moment in the user list thread:
"xcap server - http load–balancer: xcap authentication problem"
Maybe you can have a look.
Best regards,
Henning
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Bucur Marius -
Henning Westerholt -
Paul Pankhurst