The best way (performance-wise) to get History Messages that are older than 2 days

Hello everybody,

we recently noticed the limitation in openfire that it wont return History-Messages in MultiUserChat Rooms that are older than 2 days.

Well, this is not completely true, but if you restart the server you will never get HistoryMessages that are older than 2 days…however, as long as you do not restart the server you will get as many HistoryMessages as saved in the cache(?).

I now want to provide a custom IQ to request Messages from a room that are older than a provided timestamp.

So, what I would send is something like:

      <room>mucjid@mucservice.com</room>

50

1234567567

So, the client would provide a timestamp, a number of messages that it wants to receive and the room for which it needs the messages.

The plugin would now have to find the next 50 messages that have a timestamp smaller the provided client-timestamp.

The way to get this messages is pretty much straigt forward I guess…however, I am afraid that this will perform badly in a table such as ofMucConversationLog with a lot of entries…

Does anybody have any idea on how to get a nice performance here?

One of my ideas is to read all messages belonging to this room once the client that could send the above IQ enters the room.

We could then filter locally and wouldn’t have to access the database directly all the time.

Maybe somebody here already attempted this and (hopefuly) succeeded.

Thanks in advance!

Can anybody confirm the following assumption?

“ChatMessages that are not part of a RoomHistory are saved in the ofMucConversationLog table”

I am asking this because I can only get access to all ChatMessages if those that are older than two days are not part of the MessagesCache but then are guaranteed to be written to the ofMucConversationLog.

We definetly need a way to get HistoryMessages that are older than two days…but every manual attempt fails due to misunderstandings in either the API oder the timing when data is saved from cache to the Database.

I still hope we got somebody here that already tried getting this to work.