Room Properties Change After Service Restart

We have openfire connected to MS SQL. We use about 15 group chat rooms. The normal config for each is to log the conversations and enable presence broadcast for participants and visitors only (mods are hidden).

The issue occurs when restarting the openfire service. Once restarted, the group chat room properties (name, description, etc.) seem to shift around without any rhyme or reason. Example: Room sales@servername will be named Accounting and broadcast presence will be set for moderators only.

This means everytime the service is restarted, or if the server itself has to be restarted for maintenance, we have to log back into the admin console and play cleanup for 15-20 minutes on each of the group chat rooms, making sure the names/ids/etc match.

Any ideas what might be causing this?

Update.

Did some digging in the SQL DB. The ofMucRoom table was showing duplicate room IDs. Both in the pair shared the same modificationDate, naturalName, and description, which leads me to believe that openfire was updating rows in the table based upon roomID.

I destroyed a test room in the admin console, and it no longer shows up in the admin console, but it still appears in the ofMucRoom table.

My thought is, when old rooms were destroyed, they remain in the table, and new rooms being created may end up using the same roomID, so things get scattered when the service restarts.

The question is why do rooms appear in the table that don’t appear in the admin portal? Is there another place it stores just the list of MUC rooms?

Update 2.

Okay, now we’re getting weird.

  1. Create a room in admin panel.

  2. Verified that the new room shows up in admin panel and DB table.

  3. UH-OH! New room in table is now sharing roomID with a pre-existing room.

  4. Delete test room from admin panel.

  5. Verify test room is no longer listed in admin panel or DB table.

  6. UH-OH! Pre-existing room is now gone from the DB table, but still shows up in the admin panel.

Something tells me when I restart the service, that pre-existing room will disappear too.

Anyone else experiencing these issues?

Update 3.

Think we’ve found a solution.

The table ofID stores values used to increment things, such as new group chat room IDs, which is idType 23.

A while back we had an issue where the transaction logs were full, due to a failed backup. We fixed that problem, but my suspicion is that during that time when the DB was basically in read-only mode, this value didn’t increment correctly.

This would explain why new rooms would be given the same roomID as existing rooms, which was causing all sorts of fun issues.

To test this theory, I set the value of idType 23 in table ofID to a number higher than any of the existing roomIDs. I then created a new room, and saw that it was given a unique roomID. I destroyed it, and again no issue.

The next test will be tonight, after business hours, when we restart the openfire service. I have a feeling we’ll need to recreate a few rooms, but that should fix the issue moving forward.