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(a)1und1.de>
To: sr-dev(a)lists.sip-router.org
Cc: Paul Pankhurst <paul(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev