Hello,
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.
Example:
<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> <last>990</last> <count>16</count> </set> </fin> </message></body>
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(); eventsQueue.addGroupChatEvent(conversationManager.getRoomConversationKey(roomJID), 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_MESSAGES: 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?