Improve Robustness of loading MUC service at startup

Description

Openfire user ninjatek noted that his MUC service named 'conference' was not loading at startup. The problem was isolated to having a "blank" entry in the ofMucServiceProp database table for names "sysadmin.jid" and "create.jid".

MultiUserChatServiceImpl.java#initializeSettings

"JID" would then throw an exception and the startup process would halt.

ninjatek removed these two entries in the database and then hit a problem with having only 3 of his 180 rooms load. This would appear to be a problem with the massive try{} block in MUCPersistenceManager#loadRoomsFromDB that does not print a non-SQL exception. This may not be an issue, but Guus is refactoring now.

The other issue was openfire checks the ofMucRoom table emptyDate for entries that are only more recent than either 30 days old or whatever "unload.empty_days" days is set up. Setting that to a very large number caused all rooms to load.

Environment

None

Activity

Show:

Guus der Kinderen February 12, 2013 at 10:19 PM

Most SQL exceptions will now cause one room to be skipped, not all rooms from that point onwards. Additionally, parsing of sysadmin.jid and create.jid properties now checks for empty values (and ignores them).

User ninjatek confirms that this alleviates the problems (based on an old database backup that still had the original 'bad' data).

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created February 12, 2013 at 8:30 PM
Updated February 12, 2013 at 10:19 PM
Resolved February 12, 2013 at 10:19 PM