[sr-dev] git:master: modules_k/presence Fixed DB Storage Modes

[Klaus Darilion]

On 20.02.2012 11:52, Anca Vamanu wrote:
> Hi Klaus,
>
>
> On 02/20/2012 10:54 AM, Klaus Darilion wrote:
>> Hi Anca!
>>
>> I wonder what happens if I build a server cluster (p1 and p2) with
>> subs_db_mode=3 and publ_cache=0.
>>
>> Then a subscription to user1 is received from p1 and stored into the DB.
>> Then user1 sends a publish via p2, which is stored in the DB.
>>
>> Who will send the NOTIFY for the subscription? p1 or p2? I guess p2 as
>> p1 has no idea about the publish - correct?
> The machine that received the Publish, in this case p2 will send the
> Notify. Looking now in the code, I saw that when sending out this
> Notify, p2 will actually put in the Contact header the contact of the p1
> (initial contact). I don't think there should be any problem with this (
> except someone compares Via and Contact, but probably not). In this way
> always the reSubscribes will get to the same machine.

Makes sense.

> I see now an opportunity to improve the performance because of this
> behavior - having a mode in which to read from memory for Subscribes,
> but always read from DB for Publishes.

What if publ_cache=1. What really happens on incoming PUBLISH?

I have not read the code but I suspect with subs_db_mode=3 and 
publ_cache=0 the module does (without permissions checking):

incoming PUBLISH without e-tag:
INSERT INTO presentity .....

incoming PUBLISH with e-tag:
UPDATE presentity ... WHERE etag='..' AND ......

incoming SUBSCRIBE without to-tag:
INSERT INTO active-watchers ...
SELECT * FROM presentity WHERE ....

incoming SUBSCRIBE with to-tag:
UPDATE active-watchers ...
SELECT * FROM presentity WHERE ....

So what changes if publ_cache=1?

thanks
Klaus



>
> Regards,
> Anca
>
>> thanks
>> Klaus
>