I have had a user from a remote Wildfire server cut-n-paste messages to me, and the client decided to send each line of the cut-n-paste as a separate <message/> (dumb client, but there ya go).
Because it was a single cut-n-paste and thus nearly instantaneous, but multiple messages, they ended up out-of-order when they arrived. This was private messages, no MUC involved, but still involving an s2s connection.
Jeff McAdams added a comment - 02/19/07 04:25 PM FWIW, this problem is not isolated to MUC.
I have had a user from a remote Wildfire server cut-n-paste messages to me, and the client decided to send each line of the cut-n-paste as a separate <message/> (dumb client, but there ya go).
Because it was a single cut-n-paste and thus nearly instantaneous, but multiple messages, they ended up out-of-order when they arrived. This was private messages, no MUC involved, but still involving an s2s connection.
I can confirm that this issue can happen when using Connection Managers also.
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.
Yann Biancheri added a comment - 04/27/07 09:16 AM I can confirm that this issue can happen when using Connection Managers also.
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 has 5 connections (blocking io, mina is not used in that part) to OF and the
incoming traffic for each connection is handled by 5 threads
This mean that a stanza coming from a particular client will be randomly handled by 1
of this 25 threads.
...
even if stanza arrived in the right order there might be processed at the same time in different threads!! This can lead to a lot lot of troubles due to concurency issues and we can expect some crazy behaviours nearly everywhere."
So one should make sure that "each client has a dedicated thread server side for processing incoming stanzas" no matter if connected directly where this is already the case or if it is connected via a CM.
CM has 5 connections (blocking io, mina is not used in that part) to OF and the
incoming traffic for each connection is handled by 5 threads
This mean that a stanza coming from a particular client will be randomly handled by 1
of this 25 threads.
...
even if stanza arrived in the right order there might be processed at the same time in different threads!! This can lead to a lot lot of troubles due to concurency issues and we can expect some crazy behaviours nearly everywhere."
So one should make sure that "each client has a dedicated thread server side for processing incoming stanzas" no matter if connected directly where this is already the case or if it is connected via a CM.
Bug
Open
Minor
FWIW, this problem is not isolated to MUC.
I have had a user from a remote Wildfire server cut-n-paste messages to me, and the client decided to send each line of the cut-n-paste as a separate <message/> (dumb client, but there ya go).
Because it was a single cut-n-paste and thus nearly instantaneous, but multiple messages, they ended up out-of-order when they arrived. This was private messages, no MUC involved, but still involving an s2s connection.