5 Apr
2004
5 Apr
'04
5:18 p.m.
On 04-04 20:49, Alex Bligh wrote:
OK, I thought that you were using db_mode 2. Mode 2 will not complain
about this because it does all writes in background. Mode one is does
all reads and writes immediately so if db fails then the request
fails.
You are right, in db_mode 1 ser should recover, I will fix this,
thanks a lot !
Jan.
Jan,
I see, please restart the server to see if it disappears. If yes then
it is working as expected, if no then there is a bug in usrloc.
No, it should not get into this state. All
expired entries should be
deleted in the next timer run once they are loaded into the memory. To
find out why it does not happen in this case, enable debugging,
restart the server and let it run (until the cleanup timer hits). It
should print some error messages.
OK - I have been deliberately avoiding restarting ser in case it clears
the condition just through the restart, and I lose some data that would
otherwise be useful for debugging. Can you confirm there's nothing else
useful I can find? The server hasn't been restarted since this happened. No, this
should not happen. When you restart the server it loads all
the contacts from the database into memory. If an update comes
(REGISTER message) it will update the entry in the memory and then it
tries to update the entry in the database. The entry in the memory is
valid even if the database update fails. That way ser can work even if
database connection is broken.
That (the entry in memory being valid even if the database update fails)
/doesn't/ seem to be happening. The database update is failing, and that is
causing ser to 500 the REGISTER, and the internal memory copy does not
update (or "serctl ul show" would show the new copy). So it seems that
there can be at least one database update failure mode where the entry in
memory does not update, and ser does not continue to work.
I'm using db_mode 1 if that helps any.