powered by Jive Software

How does the cache behave on server shutdown?

Hello everybody.

The following happened today:

On our 3.9.1 openfire we had a bot running spamming rooms with messages (this was done on purpose).

We also have the Archiving Plugin running.

Before the shutdown the ofMessageArchive got 7k entries…so, 7k messages.

The ofMucConversationLog has only 700 entries…I believe this was due to most messages beeing cached.

We then restarted openfire.

The ofMucConversationlog was still at only 700 entries…so, where did all the messages go?

All of our RoomHistories for every MUCRoom did loose all their messages.

Something really fishy is going on here.

So, my question is what happens with the cache on server shutdown.

Is it written to the Database or dumped in a file and then read on server start again?

Thanks in advance.

Check your MUC room configuration(s). There is a setting to enable the conversation log for each room, and you can set the default room configuration (for newly created rooms) using the MUC service configuration. Both are available via the Openfire console.

Thanks for the reply.

I am well aware off those settings.

I created a new GroupChatService and changed the default settings to log all messages and I also set the History Settings to return all messages.

This is not the problem.

The problem is that the cache got lost on reboot or did not get rebuild on reboot.

So, I really need to know how the cache is supposed to work.

Thanks in advance

Thanks wroot,

so its all related…

The “funny” thing is that this did not happen all the time.

We had several restarts before and everything was fine.

The “lost cache” happened only when there were like 7k messages stored in the cache…so, it all seems to come down to broken cache behavior…propably…

I am not an expert at openfire, but we use openfire as a backend for our chatting solution and I am in charge of handling this backend.

To answer your question, the normal shutdown behavior is expected to write out the queue of pending conversations to the DB for a properly configured MUC service.

MUC messages are held in a queue of a non-configurable fixed size (currently 100000). If this fixed limit is reached, no new messages will be added until some existing messages are written to the DB and removed from the queue. When this happens you would expect to see one or more error messages in the error log.

While the service is running, there is a configurable “flush” task that is expected to be running in the background for each active MUC service. By default this task runs once every five minutes (300 seconds) and flushes up to 50 pending MUC messages per task execution. Under even moderate load, this will not be nearly sufficient and should be configured with more appropriate values (via the “Other Settings” page of the corresponding MUC service).

It is possible that during shutdown there was an exception of some kind that would prevent the MUC service from properly flushing the queue (again, there should be evidence in the error log). In this case, the messages will be lost.

Overall it seems to me that the current MUC logging implementation has default configuration values that are far too small/infrequent for a production deployment, and that the overall persistence model is overly brittle. Definitely warrants a second look (via OF-764).