Monitoring Plugin for archiving

Hi,

I’ve been experimenting with message archiving and found open archive for xep-0136.

I tried using xep-0136 and it worked wonderfully in my early tests but currently on a clustered openfire setup, I’m getting a " Error saving archived message com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException: Duplicate entry… ". It uses the SequenceMananger,nextId for its primary key in its database insertions; I’m not sure if there is any way to get SequenceManager to work on a clustered envirnment and thus this leads me to consider other options, namely monitoring plugin.

Based on the code of monitoring plugin, it somehow supports clustering

/**

  • Manages all conversations in the system. Optionally, conversations (messages plus

  • meta-data) can be archived to the database. Archiving of conversation data is

  • enabled by default, but can be disabled by setting “conversation.metadataArchiving” to

  • false. Archiving of messages in a conversation is disabled by default, but

  • can be enabled by setting “conversation.messageArchiving” to true.

  • When running in a cluster only the senior cluster member will keep track of the active

  • conversations. Other cluster nodes will forward conversation events that occurred in the

  • local node to the senior cluster member. If the senior cluster member goes down then

  • current conversations will be terminated and if users keep sending messages between them

  • then new conversations will be created.

  • @author Matt Tucker

*/

Is there a way to expose the archive to xmpp clients (via xep0136) without using another plugin (like open archive); moreover, if it runs archiving concurrently with open archive, will there be any issues?(would messages be doubled in the archive?)

I’m thinking of just disabling openarchive’s archiving functionality and limiting it to support xep0136 fetching. Apparently they both use the same schema, which makes this idea seem feasible. What do you guys think?

Best Regards,

Stevenson Lee

.

See http://community.igniterealtime.org/message/224596#224596