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

[Klaus Darilion]

I actually also meant the hot-standby scenario. So all you had to do was 
to change the totag generation to be identical on both sides? Still a 
hack but it will work ;-)

Of course this hack only achieves HA, but does not improve scalability. 
The new modes will allow multiple presence servers in active-active 
setup, but moves the bottleneck to the DB. Maybe some caching can be 
used depending on dispatching configuration of the load-balancer. I 
guess I have to think some more about that.

regards
Klaus

On 20.02.2012 12:03, Anca Vamanu wrote:
> Hi Klaus,
>
> It's not quite the way you described it. In the scenario describe by me,
> p2 was just a hot stand by, sending nothing outside while in backup
> mode. In an active - active setup, it is a lot harder to achieve.
>
> First, as Daniel suggested, send() is the best option to use when
> replicating - forwarding the message as it was received.
> Then, p2 should work in a synchronous way - generating the same tag and
> Via branch as p1. With the Via branch it is easy to achieve with the
> *syn_branch* global parameter. With the tag, some coding needs to be done.
>
> P2 should not send anything out, it should be blocked at network layer,
> or from inside the application. However it will have the impression it
> had send out the Notifies, so it has to receive the replies for it. This
> is why p1 must also replicate replies for Notifies.
>
> Regards,
> Anca
>
>
>
> On 02/20/2012 12:43 PM, Klaus Darilion wrote:
>>
>> Hi Anca, that sounds like an awful hack ;-)
>>
>> Just to be sure that I really understand the hack - for example presence
>> server p1 and backup presence server p2.
>>
>> p1 receives SUBSCRIBE: local handle_subscribe() and t_replicate() to p2
>>
>> p1 sends back 200 OK and stores dialog.
>>
>> p2 sends back 200 OK to p1, but using a different to-tag thus having
>> another dialog. Thus, NOTIFYs by p2 have a different Via branch-id and a
>> different from-tag. Thus, I wonder how failover to the backup-node
>> should work and how the backup node will accept a faked NOTIFY-response
>> if branch-param and from-tag are different ???
>>
>> thanks
>> Klaus
>