[Serusers] Re: Strange error on registration

Alex Bligh alex at alex.org.uk
Sun Apr 4 21:49:17 CEST 2004


Jan,

>   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.

>> b) ser does not recover gracefully from this state (requires manual
>>   intervention). I /think/ what is happening here (and I haven't
>>   done a full code inspection) is ser tries to write into the
>>   database, it fails because a line with the same (username,
>>   domain, contact) 3-tuple is already there, but then it can
>>   as that entry is already expired, it never seems to get purged,
>>   and ser gets stuck.
>
>   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.

>   The only situation I can imagine this could happen is when database
>   delete fails. The entry is removed from the cache but it is still
>   present in the database. In such a situation subsequent inserts and
>   updates will fail. But ser should recover after restart because it
>   will reload all entries.

OK I'll try that when we know all the data is there (though I guess
I could simulate it by manually inserting a bogus line into the
mysql table).

Alex




More information about the sr-users mailing list