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