[Serusers] Location table issues

Jan Janak jan at iptel.org
Mon Oct 4 03:03:11 CEST 2004


On 28-09 12:51, Andrei Pelinescu-Onciul wrote:
> On Sep 26, 2004 at 13:56, Michael Shuler <mike at bwsys.net> wrote:
> > I figured that's what people would say :( thanks though.
> > 
> > I thought of that but the problem is that it takes up to the max time of my
> > longest REGISTER client timer before its back in sync with the one that runs
> > off the DB.  It would be nice if there was a 3rd option i.e.
> > modparam("usrloc", "db_mode", 3) that would make it read only at startup to
> > "seed" the memory database.  The reason I need this is because I have a few
> > SER servers behind a Foundry ServerIron XL layer 4 switch.  When I bring the
> > failed server back online the Foundry automatically recognizes that port
> > 5060 is alive again and immediately starts sending it traffic.  If the RAM
> > based location table hasn't been fully populated by the time this happens
> > then we have a bunch of failed calls until it syncs up which in my case is
> > up to 5 min.  I can get around this manually by removing it from the cluster
> > config in the Foundry but that takes away from the automation of the whole
> > thing.
> > 
> > Andrei/Jiri, what do you guys think of adding that as an option?  It seems
> > to me that it would be the most logical way to go about doing it and should
> > be very easy to do since all it is combining parts of mode 0 and 1/2.
> 
> Yes, it would be trivial to add it and I like the ideea.
> Let's see what Jan has to say about it (he is usrloc and registrar
> maintainer/author).

  I have a separate function for that called save_memory. That function
  updates memory cache only, it does not update the database.

  The solution then would be:

  if (srcip == other_ser_ip) {
        /* Replicated request, update memory only */
  	save_memory("location");
  } else {
  	save("location");
  };

  I will commit the function into the public CVS if it is not there yet.
  Please expect some delay, I am currently travelling.

     Jan.




More information about the sr-users mailing list