Re: [reSIProcate] InMemoryRegistrationDatabase
Matthias Moetje - TERASENS GmbH wrote:
Hi,
I have a question about the following comment regarding
the InMemoryRegistrationDatabase:
/**
Trivial implementation of a persistence manager. This class keeps
all registrations in memory, and has no schemes for disk storage
or replication of any kind. It's good for testing, but probably
inappropriate for any commercially deployable products.
*/
So what is the problem with this? Imagine the server is
restarted. All clients will register every like x s (e.g. 70),
so all clients will be re-registered within x s.
OK, for multiple servers working with the same registration
database it makes sense, to persist that to disk, but for
a single server application that goes down we would have
downtime + x s with InMemoryRegistration and downtime
registration persisted to disk. Is this correct or am I missing
something here?
If you have lot's of client's who's addresses change infrequently, then
you may have an expiry of 30 minutes or maybe even 60 minutes. Less
frequent registrations means less load on the server.
Now, let's say you need to deliberately restart the server for an
upgrade or something. You probably don't want to wait 30 minutes for
all phones to be active again. Therefore, it might be desirable for
InMemoryRegistrationDatabase to have a convenient method for dumping
everything to a stream, and another method for loading data from a
stream. If you are worried about server crashes, you could call this
method every minute or even every time a registration takes place. It
may not be as efficient as SQL, but it would give your users a better
experience.
Matthias Moetje
------------------------------------------------------------------------
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel