Good point. So then perhaps t_replicate() [AND] save_memory() should be used as normal. And SER should then just start up using a lazy-loading mechanism. Eventually all SER routers in the farm would then have a fully populated cache and the problem would be solved.

In other words the SER server that physically recieves the original REGISTER message would save() and t_replicate().

All the peers in the farm that receive a REGISTER via the t_replicate() function would only use save_memory().

MySQL replication still occurs and if a SER server is restarted it doesn't attempt to load usrloc info upon startup, but rather loads it over a period of time. All the while, if a usrloc record is looked-up and it is on in cache, then SER would query MySQL for the correct ucontact record.

Thanks for the qustion --- I hadn't thought about that before.

Regards,
Paul

On 5/30/05, Karl H. Putz <kputz@columbus.rr.com> wrote:
>-----Original Message-----On Behalf Of Jiri Kuthan
>Sent: Monday, May 30, 2005 5:36 AM
>At 03:40 AM 5/30/2005, Java Rockx wrote:
>>Currently, usrloc is replicated via t_replicate() using db_mode=writeback.
>>
>>However, our lazy-load patch would obsolete the need for
>t_replicate() because we have multiple MySQL servers that are
>active-active so __all__ replication really occurs at the database
>layer rather than the SIP layer.
>
>So this is the point which I am still struggling with. I mean
>generally there is a problem
>of read-write intenstive UsrLoc operations. We can move it from
>SIP to DB. However, whichever
>layer we choose to solve the problem, it takes careful
>dimensioning. Otherwise the
>replication mechanism may cause peformance problems.
>
>What Mysql setup are you exactly using? Cluster? Master/slave replication?
>
>Otherwise I think that the cache policy "load-on-demand" makes sense.

If pure DB replication is used, what would happen in the following scenario:

A given user receives multiple calls such that more than 1 physical SER
server has userloc
cache populated.

The user then phsyically moves or changes return contact registration
information and re-registers.

It seems that the specific SER server that handled the registration would
update cache and the
backend DB would be updated.  But any attempt to contact the user through a
SER server that has
not yet expired the old cache info would fail.


Karl

>
>-jiri
>
>_______________________________________________
>Serusers mailing list
>Serusers@iptel.org
>http://mail.iptel.org/mailman/listinfo/serusers
>


_______________________________________________
Serusers mailing list
Serusers@iptel.org
http://mail.iptel.org/mailman/listinfo/serusers