I’'ve obsered some strange behaviour on openfire lately. Some of my users are receiving message not in the order there where sent.
User 1 sends a first message stanza to User2 whose content is “Hello”
Shortly after User 1 resends a message stanza to User1 saying “How are you?”
User 2 receives messages: “How are you?” and then “Hello”
This is the component I’'m using:
OpenFire (OF) 3.1.1
2 Connection Manager (CM) 3.1.1
I’'m suspecting some troubles in the way the Connection Manager works. In the CM configuration we have specified that we want 10 connections between each CM and OF.
When a user sends a stanza through the CM, the CM receives it and ‘‘randomly’’ choose one of the connection to forward it to OF.
When sending two stanzas, they can be routed through two different connections and OF has no way to know which stanzas has arrived first. By doing so, we can loose ordering. I beleive that clients should be assigned to one and only one connection on the CM so that we are sure to maintain ordering.
CM route the iq auth to OF through a different connection than the one used in step 2.
For some reason, on the OF side, the iq auth is received prior the session creation notification. Since the stanza is received for a non existing session the iq is discarded and the client is then desperately waiting for an answer.
This is just some thoughts and I have no proof that this is really what happens, but it seems to me as a possible explanation.
this problem is already known as JM-835 but unfortunately not yet fixed. Vote for it to make it a high-priority issue but with currently one vote it seems to be less than important for most users.
this problem may be related to the number of connections, I think five is still the default ( in manager.xml). Reducing these to one could solve this problem.
I have no idea how performance will be after changing this value.
I’‘ve tried to reduce the number of connections between the CM and OF. For sure it makes this issue less probable but doesn’'t solve it.
Reducing the number of connection to one will solve the problem for sure. Therefore we’'ve discovered some serious isssues in WF-CM 3.1.1 which will cause connections between CM and WF to be unavailble until the message is sent to the end users.
In our environment, lowering the number of connections between CM and WF increases the chance to observe delays in stanza delivering (can be up to 20min).
We haven’‘t reported the issue in the forums since it doesn’'t occurs with latest version 3.3.0 that uses NIO. We are currently planning to move as fast as possible to the newest version.
Basically with version 3.1.1 a single client with a bad network connection (or bad intention) can easily block all traffic from the CM and WF and causes the whole system to be unavailable to other users.
I can detail the process to block WF working with CM prior NIO if you want. Basically I strongly discouraged people to use a CM prior NIO in there production environment this it creates more issues than solutions.