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?