Open Archive + Openfire on Windows = non-threaded logs

When I view the logs in Open Archive the messages are disjointed. I only see half of the conversation at a time. See the attached images for examples and config.

I’ve got the same thing on a Linux server (Fedora 7).

Strange thing is some conversations are threaded like they are supposed to be, and others are not.

I forgot to mention that is the case here also. And it can be conversations between the same 2 people. there does not appear to be any reason to when it does or doesn’t work.

I have the same issue as well…it seems to log the first conversation of the day just fine, but then the rest are seperated by the user name and not conversation. And when I try to rebuild the index it fails…every time.

Same thing here on MSSQL.

When SELECTing the conersation elements to be displayed from the archive when searching, it looks like the program SELECTs them by CONVERSATIONID which changes depending on the direction of the conversation. Therefore only half of the conversation is visible. If the CONVERSATIONID remained the same for the conversation then this wouldn’t be a problem.

I have manually changed the values in the SQL db to reflect what should be happening i.e. the CONVERSATIONID remaining the same, and it all works splendidly.

Can anyone see in the code why the program changes the CONVERSTIONID even for the same converation?

Are there any simple steps to reproduce this issue?

Not to sound negative, but it is really simple to replicate this. Install the plugin on any of my servers enable it and the try to read the logs. It is guaranteed to be disjointed.

Here is my openfire config if it helps any.

Agree that it is easily replicated.

What do we do to get the developers attention?

I looked at this product, but due to the archive issue, have moved onto SoapBox which seems to work out of the box. I do prefer Openfire, but without proper archiving cannot even consider deploying it.

I do understand that this issue really bugs you and that it’s easy for you to reproduce.

Having just checked my conversations of the last week revealed no single case of the problem though. I’ve chatted with local users, with remote xmpp user and with users on ICQ - in each case it just works

You certainly have my attention but without being able to reproduce the issue it’s hard to solve it.


What is your configuration? Are you using LDAP?

Hi Stefan - aren’t these other guys in this thread having the same problem as me?

Hi mtstravel - yes we are using active directory, does this make a difference?

Active Directory based LDAP here as well.

I am running with OpenLDAP

Yes I think so - maybe I am the only one where it actually works

Mine will work from time to time, but not for every conversation. With mine it almost seems like when someone closes the chat window it won’t string the conversation, but from what my IT guys are telling me, they keep the conversation open. I checked the logs for the past week and it seems to be half and half, so I can’t point it at one thing.

SRT did you elect to use OpenFire’s integrated sql db or using an external?

For mine, I chose to use the default intergrated db and not sure if this has anything to do with it.

The database type does not seem to be the factor. I have tried with both the embedded and mysql databases.

Maybe you could provide some detail on your configuration since it works for you. Stuff like what version of openfire, settings for your plugin, othe openfire settings that may have an affect, database type, etc.

Openfire 3.4.5

Ubuntu 7.10 amd64

Sun JDK 6u04

MySQL 5.0.45

Users are in LDAP (OpenLDAP 2.3.35)

Plugin Settings (only archive.enabled is set):

archive.enabled = true


<?xml version="1.0" encoding="UTF-8"?> <jive>
    <!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local
         or remote users. -->
    <!-- <authorizedJIDs></authorizedJIDs> -->
  <!-- Network settings. By default, Wildfire will bind to all network interfaces.
      Alternatively, you can specify a specific network interfaces that the server
      will listen on. For example, This setting is generally only useful
       on multi-homed servers. -->