MUC Room ConversationLog

Openfire Openfire Dev
1

I think there is a serious issue with the MUCPersistenceManager. When it is getting the history for a room from the database it arbitrarily decides to cut off the history at 2 days. This prevents it from returning the correct number of messages if a client asks for it, or if it is configured that way in the Group Chat History Settings. If the number of messages needed is greater than what is available in two days, for a room that has many messages but maybe not a lot of activity, it fails to return the correct number.

The XEP that it fails: http://xmpp.org/extensions/xep-0045.html#enter-history.

This might require a fetch or top SQL statement to get the correct number of results, these are very database dependent. How has Openfire handled database dependent work like this issue? Thank you for any input.

2

Ian,

What you are describing is what only happens at startup of openfire, once running, it obeys the chatroom history a-okay (it is read from cache and not from the database). Yes, it is a feature that would be nice to add.

daryl

3

Openfire also removes the chat room from memory if there is no activity for 30 days. Our rooms are often large and last a long time, but sometimes have no activity for days.