XEP-0313, MUC and stanzas in database


I am working with an installation of Openfire v4.0.2 with Monitoring Service plugin v1.5.1 and have encountered strange behaviour upon requesting the MAM-archive of a multiuser chat: it was returning the fin statement with (mostly) correct count of messages, but without said messages.


<body xmlns='http://jabber.org/protocol/httpbind' ack='2446734937'>
    <message to="username@servername/instance" xmlns="jabber:client">
        <fin xmlns="urn:xmpp:mam:0">
            <set xmlns="http://jabber.org/protocol/rsm">
                <first index="14">922</first>

Upon each such request there also has been an exception in an Openfire at com.reucon.openfire.plugin.archive.xep0313.IQQueryHandler.sendMessageResult(IQQu eryHandler.java:229) (or :226 for current master branch version) - that is, org.dom4j.DocumentHelper has received a premature end of file in attempt to parse the stanza.

In attempt to understand what is happening I have dug through the Openfire source code and encountered the following (org.jivesoftware.openfire.archive.GroupConversationInterceptor):

public void messageReceived(JID roomJID, JID user, String nickname, Message message) {
    // Process this event in the senior cluster member or local JVM when not in a cluster
    if (ClusterManager.isSeniorClusterMember()) {
        conversationManager.processRoomMessage(roomJID, user, nickname, message.getBody(), new Date());
    else {
        boolean withBody = conversationManager.isRoomArchivingEnabled() && (
                conversationManager.getRoomsArchived().isEmpty() ||
                        conversationManager.getRoomsArchived().contains(roomJID.getNode()));         ConversationEventsQueue eventsQueue = conversationManager.getConversationEventsQueue();
                ConversationEvent.roomMessageReceived(roomJID, user, nickname, withBody ? message.getBody() : null, new Date()));

I read this as that complete stanzas of MUC messages are not saved to the database, but only added to the history as events to be re-fired upon connection to the chatroom. Because of that, the SQL query that is constructed by com.reucon.openfire.plugin.archive.impl.JdbcPersistenceManager and looks approximately as follows:

    SELECT DISTINCT ofMessageArchive.fromJID, ofMessageArchive.toJID, ofMessageArchive.sentDate, ofMessageArchive.stanza, ofMessageArchive.messageID, ofConParticipant.bareJID
    FROM ofMessagehive INNER JOIN ofConParticipant ON ofMessageArchive.conversationID = ofConParticipant.conversationID
    WHERE ofMessageArchive.messageID IS NOT NULL
    AND ofConParticipant.bareJID = 'username@servername'
    AND ( ofMessageArchive.toJID = 'conferencename@conference.servername' OR ofMessageArchive.fromJID = 'conferencename@conference.servername' )     ORDER BY ofMessageArchive.sentDate LIMIT 1000 OFFSET 0

yields empty fields as stanzas for the archived messages (they do have bodies, though), which, in turn, leads to the exception and strange results.

Example of a SQL query result (with addition of ofMessageArchive.body in SELECT):

fromjid       |                 tojid                |   sentdate    | stanza |         body         | messageid |      barejid    --------------------+--------------------------------------+---------------+--------+----------------------+-----------+-------------------- username@servername | conferencename@conference.servername | 1468250234805 |        | Test                 |      1475 | username@servername username@servername | conferencename@conference.servername | 1468250254946 |        | Another test         |      1476 | username@servername username@servername | conferencename@conference.servername | 1468324703144 |        | Another another test |      1478 | username@servername

So, I would like to ask whether it is a deliberate decision to disallow the mam queries to the chatrooms or an artefact?


I have exact the same problem. Could anyone suggest a solution?

I have this problem as well. Is anyone looking into this?