MUC Group Chat history

Hi,

When a group chat room is opened the history that is loaded in the group does not show all the information of previous chats for that room.

I have set the server to show the previous 1000 messages but unfortunately this does not happen.

I can view the information in the database but i can not find at what point it decides to load in only a certain amount from the MUCConversationLog table.

I have looked through the forums and spotted that only messages from the last 2 days are read in from the table. This was posted over 2 years ago though and i really hope that in the newer versions of openfire and spark this does not have to be the case.

So i need the information loaded into this history to look back at least a week or two to satisfy the requirements for spark.

Can anybody please tell me how to do this and wheather this limiting 2 day history still stands?

Thanks in advance

Kenneth

I just had a look at the source code for MUCPersistenceManager in Openfire 3.6.2. It seems that the limiting to 2 days history does indeed still stand:

        pstmt = con.prepareStatement(LOAD_ALL_HISTORY);
        // Recreate the history until two days ago
        long from = System.currentTimeMillis() - (86400000 * 2);
        pstmt.setLong(1, serviceID);
        pstmt.setString(2, StringUtils.dateToMillis(new Date(from)));
        // Load the rooms conversations from the last two days
        rs = pstmt.executeQuery();

Thanks alot for this very helpful answer Michael.

This is a very limiting feature for spark and openfire with only admin users, that can look at the database, being able to see chat history past 2 days.

I have seen alot of people dont really want any history displayed in the forums but it seems strange to limit it to 2 days for everybody else and not the say n lines i thought it would do from the setting in the servers console.

Just a quick note to anybody who needs to change to history to load in a greater amount of history

I replaced the following for LOAD_ALL_HISTORY and LOAD_HISTORY

pstmt = con.prepareStatement(LOAD_HISTORY);
// Recreate the history until two days ago
long from = System.currentTimeMillis() - (86400000 * 2);

with

pstmt = con.prepareStatement(LOAD_HISTORY);

// Recreate the history until 30 days

long daySec = 86400000;

long days = 30;

long backDate = daySec * days;

long from = System.currentTimeMillis() - backDate;

If you then simply run a dailybuild using ant and get the jars in the lib file thats created and replace the lib file with these on the current openfire server you will get a 30 day history.

Hi Kenneth,

is this the https://server:9091/muc-history-settings.jsp?mucname=conference page where you did specify 1000? I’d like to create an issue to improve the admin console and Openfire, but I should refer to the right web page.

xmpp.muc.history.maxNumber is the system property to store (default) 25 chat lines, so I guess that one would like to add another property. Maybe something like “xmpp.muc.history.mayDays”, so one can configure it.

LG

Hi LG,

Yes your right it is the https://server:9091/muc-history-settings.jsp?mucname=conference page where you did specify 1000 messages to display but at the moment with the current build this only displays the 1000 messages if they have occurred in the past 2 days which is very limiting for a persistant group chat room where users need to look at the information that was posted if they where away for say 2 weeks.

There has already being an issue raised to have the function which your talking about, of being able to specify the number of days and messages via the server which would be excellent but it was posted over 3 years ago and is still not resolved. key JM-294.

I have obviously voted for this and it would be excellent to get it into a new release of openfire as for me this is a critical issue.

“Something like “xmpp.muc.history.mayDays”, so one can configure it” - would be perfect.

Kenneth

Hi kennethf

Did this ever work? Just tried it, that is:

  • Got source code and modified the MUCPersistenceManager class

  • Recompiled and copied openfire.jar to my lib folder

  • Restarted OpenFire (actually went through Setup again)

  • Got Spark (as well as my custom C# client) to connect

And still only got messages from the last 2 days!

I’m using OpenFire 3.7.1 by the way…

Anyone tried and suceeded?

Thanks

Ignore my question… Such a nini I am.

I forgot to change the from date for LOAD_ALL_HISTORY.

Now works…

Did this two day limation ever get resolved via the admin console or a properties file?

I would like to use this feature also.

Thanks, Rahul

I have modified the code to allow selection by number of days as well.

Please find a patch attached which does the same.

Also attached is screen shot showing preference. (Only English is done - someone needs to do it for other languages)

Here is what it does:

  1. Increases the SQL database search days from 2 (current) to 7 (so new maximum limit is now 7)

  2. If number of days is 0 (zero) than it just checks based on number of lines (just like current behaviour without this patch)

  3. If number of days is greater than 0 then the rule shows history for that many days. (i.e. 24hrs*N days and newer)

  4. If “Consider days above start at midnight” then days is counted based on midnight.

Eg scenario:

Lets say current time is 3PM

Lets say number of days is 1

if midnight option is NOT checked then logs are shown from previous day 3PM to today 3PM. (i.e. last 24hrs)

if midnight option is checked then logs are shown only from 12AM to 3PM. (i.e. only today’s logs)

PS: For persistent rooms, you need to restart Openfire for any changes to take effect.

Note: this patch also fixes a bug in packetfilter plugin related to destJID option. (see patch)


openfire_history_day.diff.zip (4695 Bytes)

I know this was done quite a while ago, this is exactly what i’m looking for. I’m not a dev and wondering how i can apply this patch on my server to test.

Thanks in advance.
Manxy

Hmmm seems like good stuff, why not present it as a pull request for upstream?

It seems this is still not resolved. If there are no plans to resolve it, I think atleast the muc-history-settings.jsp admin page should make this clear. I think this is a severe and, atleast to me, unexpected limitation that should be made clear to the users. These are the options on the settings page:

Don’t Show History - Do not show a chat history to users joining a room.

Show Entire Chat History - Show the entire chat history to users joining a room.

Show a Specific Number of Messages - Show a specific number of the most recent messages in the chat. Use the box below to specify that number.

If I’m interpreting this correct, there is actually no way to show entire chat history, only the last two days, other than to patch and build openfire myself. Have I understood this correctly?

Was this changed in recent versions yet?

Not that I know of. I solved it by patching openfire to make it load the amount of messages my client requires, 30 days instead of the default 2 days. But it creates a lot of extra dev ops work.

If I understand correctly, as long as you don’t restart openfire it will keep the history according to the settings. But after a restart it ignores messages older than two days. I’m very surprised that this is the case because it means that openfire doesn’t really support persistent multi user chat rooms. I would have thought this is a very common requirement.

Wow…thats pretty bad.

Hi all, ccan any one confirm if amishmm patch fixes the server restart issue, were only the past 2 days will show in the persistent rooms ?

Thank you

Edit - Im using version 3.9.1

This ought to be fixed in OF-764 and in my testing it did made Openfire to load older history, though AffenDev says it didn’t help in his case. It was in 3.9.2 version.

Exactly.

It does not help when the server restart…cause then only the last 2 days are loaded. However, as long as the server is online it now saves up to the days you set in the new property. We got this fixed on our server by compiling it ourselfes with a small modification…already filed a bug…and this will be solved…its a rly small bugfix too.

AffenDev is referring to OF-823 whcih should be fixed for 3.10.0.