<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div>Hello Paul,</div><div><br></div><div>All the functions you mentioned deal with the "presentity" table.</div><div>The pres_htable_restore fills the presentity htable with data from the "presentity" table.</div><div>Also, update_presentity, doesn't touch the active_wtchers table.</div><div><br></div><div>The db_mode flag, is relevant ONLY for active subscriptions.</div><div>That means, reSUBSCRIBE requests will be matched with the active_watchers table.</div><div>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).</div><div><br></div><div>In fallback2db mode, the subscriptions are held in the hashtable and periodically written to the active_watchers table.</div><div><br></div><div>In
the third mode, memory only, the subscriptions are held ONLY in hashtable.</div><div><br></div><div>Best regards,</div><div>Marius</div><div><br></div><div style="font-size: 12pt; font-family: arial, helvetica, sans-serif; "><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Henning Westerholt <henning.westerholt@1und1.de><br><b><span style="font-weight: bold;">To:</span></b> sr-dev@lists.sip-router.org<br><b><span style="font-weight: bold;">Cc:</span></b> Paul Pankhurst <paul@crocodile-rcs.com><br><b><span style="font-weight: bold;">Sent:</span></b> Wednesday, July 20, 2011 2:14 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [sr-dev] DB_ONLY mode in presence module<br></font><br>On Tuesday 19 July 2011, Paul Pankhurst wrote:<br>> I’ve been looking through the presence module and have some
questions<br>> regarding the DB_ONLY mode of operation. <br>> Specifically the feature seems to rely on data not being written to hash<br>> tables in certain areas of the code, as no checking is done to verify<br>> which db_mode is being used. <br>> However there are places where the hash table is populated irrelevant of<br>> the db_mode, for example the init code calls pres_htable_restore.<br>> Additionally update_presentity seems to also manipulate the hash tables<br>> indiscriminately. <br>> Am I missing something here, or is this a bug?<br><br>Hi Paul,<br><br>i think a similar question is discussed at the moment in the user list thread:<br><br>"xcap server - http load–balancer: xcap authentication problem"<br><br>Maybe you can have a look.<br><br>Best regards,<br><br>Henning<br><br>_______________________________________________<br>sr-dev mailing list<br><a ymailto="mailto:sr-dev@lists.sip-router.org"
href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br><br><br></div></div></div></body></html>