Received messages not always processed in same order

[Anno_van_Vliet]

We have a setup which is used to test the message throughput through a XMPP system. The system is feeding groupchat messages in high volume and receiving them and validates if all messages sent are received and properly handled by the XMPP system.

In order to test that messages are correctly exchanged we have established a set of 12 groupchat messages that are send repeatedly. In a little percentage of the cases messages are received out of order even though they are delivered in order to the Smack library from the Openfire server.

We interface with the Smack API creating a new MultiUserChat object and then adding a MessageListener in order to collect the received messages.
It should be possible to reproduce the bug sending messages very quickly through a connection.
One possibility to mitigate the problem, is adding a 100 ms delay in the simulated XMPP clients between message deliveries, but this is not our preferred solution.

After code review, we suspect some subtle rewriting of the synchronisation blocks would solve the issue.

My primary question is, is this assumed a realistic problem. it is offending the XMPP spec RFC 6120, but the context in our case is highly unrealistic.

[Flow]

Which Smack version?

@Anno_van_Vliet

After code review, we suspect some subtle rewriting of the synchronisation blocks would solve the issue.

That sounds like you have an idea or at least an guess how to fix this it. Would you mind sharing it?

@Anno_van_Vliet

My primary question is, is this assumed a realistic problem. it is offending the XMPP spec RFC 6120, but the context in our case is highly unrealistic.

I am a little bit confused. In a message based system with a stable order guarantee like XMPP, and an event based implementation whose interface contract guarantees a stable order, like Smack listeners do if they are configured accordingly, it is an severe issue if this contract is broken. And I don’t think the case is unrealistic.

But since I don’t know your code nor was I provided with a minimal reproducing example, I can’t tell if this is here the case.

[Anno_van_Vliet]

It concerns the 4.3.4 release.

As it is not easy to communicate our test setup, we decided to allocate time to write a unit-test to reproduce the problem in the most cleanliest setup, and eventually we will probably be able to solve the issue ourselves.

To be continued.

[Flow]

@Anno_van_Vliet

eventually we will probably be able to solve the issue ourselves.

Hopefully this includes sending the fix upstream.