[Serusers] SER Reports "out of memory"

[Greger V. Teigre]

Jan Janak wrote:
> On 30-05-2005 14:11, Greger V. Teigre wrote:
>> For the sake of the readers, here is how I understand SER's
>> operations today:
>> 1. Usrloc is always written to cache, DB write is controlled through
>> write-through parameter
>> 2. Replication is handled by t_replicate
>> 3. Management of cache is not needed, the cache is always updated.
>> However, an updated DB (and thus dirty cache) will not be detected
>
>  I am working on that already. The entries in the usrloc cache will
>  have an additional expires value and if that value expires then the
>  usrloc code will refresh it from the database. Also there will be no
>  full cache anymore -- usrloc will cache only a portion of the whole
>  location database and old entries will be using LRU scheme.

Excellent news!

>  The cache will be empty upon startup. When SER calls lookup then
>  usrloc will search the cache -- if there is no entry or if it is
>  expired then it will load it from the database and store in the cache
>  for limited period of time. If there is no entry in the database then
>  it will create a negative cache entry (to limit the amount of
>  unsuccessful database queries).
>
>  Database updates will not assume anything about the state of the
>  database so it should not matter if the entry still exists / does not
>  exists / has been modified..

I assume another ser server receiving an update must both write to DB and do 
a t_replicate to other ser servers who then do save_memory() as Paul 
responded in his last email to Karl?

>  There is one drawback though -- nathelper as it is implemented right
>  now will not work anymore -- we would need to rewrite it to use the
>  contents of the database.

Are you referring to the ping feature only or are there other things as 
well? Reading all NATed devices from DB every 30 seconds?

>> I must admit I often fall for the argument: "let each system do what
>> it is best at."
>> Following that, replication should only be done at an application
>> level if the underlying database is not capable of doing it (if we
>> agree that a DB is good at replication).  The only thing I see a DB
>> is not capable of, is handling the NAT issues. So, if a given usrloc
>> has to be represented by different location (ex. the registration
>> server), then the DB cannot do replication. However, if the NAT
>> issue is handled through some other means, ex. Call-Id aware LVS
>> with one public IP, then the usrloc should be the same across DBs
>> and the DB should handle the replication.
>
>  Another approach would be to let the user agent handle NATs. Sipura
>  phones, for example, can register with two proxy servers.

Yes, good point. But I'm not aware of many other user agents with such 
support yet?!

g-)