MUC messages in wrong order when connecting

For a long time I’‘ve used an ejabberd server but yesterday I migrated it to wildfire. One issue I’'ve noticed since then but not before is that when I connect to a MUC the history is sent in the wrong order. One random message of the last 20 is displayed last and also recieved last according to the xml console in Psi.

The MUC is hosted by jabber.ru (it is he psi chatroom) and runs on ejabberd. When my server was ejabberd I never had these troubles as far as I can remember. Is there some way for me to fix it while using wildfire?

Hi,

I’'ve also seen this behaviour of Wildfire and it would be nice to retrieve the messages in the right order. http://www.jabber.org/jeps/jep-0045.html#enter-history does not require the server to send the packets in a special order. So it seems that the client should sort the messages.

I wonder if also some other users would also like to see Wildfire to send the messages in the right order.

LG

Even if there is no requirement order I’'d say that there is no good reason to send them in the wrong order. The messages are meant to be read by a human and are most likely stored in the correct sequence somewhere so sending them in another order seems inefficient. Allowing a client without sorting capabilities to list messages in the right order would help.

I tried using Spark 2.0.1 and it seemed to get the messages right, but I am not sure if that is if because it sorts the messages right or if messages are sent right to Spark but not to Psi. Any enlightenment on the matter is appreciated.

Hi,

As a matter of fact, there is an advantage of strictly maintaining asynchronous nature of the platform. At least in this particular case, the server is not burdened with performing sorting algorithm. If the server does the sorting then it has no choice but to do sorting for every request to return chat messages. This certainly will impose a serious overhead if the number of chatters and messages is large. If the sorting is done on the clients’’ side, the sorting would be distributed. IMHO, it’'s the clients that are to be programed to adapt to the asynchronous environment.

Just my $0.02.

Hi,

do you see this only for MUC’'s which are not on your server?

I talked to Gato (the #1 developer) and he has “the s2s out of order issue” on his ToDo list.

LG

I’‘ve only seen it against conference.jabber.ru because all chatrooms I’'ve joined are there.

I’‘ve been able to repro this problem with Spark 2.0.1 talking to Wildfire 3.0.1 through a connection manager, with MUC on the wildfire server. I’‘m going to get some more details together than I’‘ll post the whole deal. I suspect that I won’‘t be able to repro it when talking directly to the server on which MUC is running; rather it’'s about the behavior of the connection manager (which is probably implemented in a similar manner to s2s where this is apparently a known issue).

What’'s interesting is that not only is the history out of order, but the order changes each time I re-join the room.

The actual MUC history is stored as a linked list, so there really doesn’‘t seem to be a way for it to get out of order. But it’‘s relayed as a series of post-dated messages, so if somewhere in between the client and MUC there is something not providing FIFO delivery then things could easily get out of order. I don’'t think FIFO is a requirement of the Jabber protocols…


Here are some examples, using Spark 2.0.1 and Wildfire 3.0.1. First, a baseline test, Spark talking directly to wildfire. The MUC history is returned in order consistently.

kenhamer has joined the room.

: This room is not anonymous.

davidyar: Yes I can see history

davidyar: Just that one message though

davidyar: Message #1

davidyar: Message #2

davidyar: Message #3

davidyar: Message #4

davidyar: A Message

davidyar: B Message

davidyar: C message

davidyar: BEGIN Session #1

davidyar: Session #1 Message #1

davidyar: Session #1 Message #2

davidyar: Session #1 Message #3

davidyar: END Session #1

davidyar: BEGIN Session #2

davidyar: Session #2 Message #1

davidyar: Session #2 Message #2

davidyar: Session #2 Message #3

davidyar: END Session #3

kenhamer: Foo

kenhamer: Bar

kenhamer: Baz

kenhamer: Fi

kenhamer: Fie

kenhamer: Fo

kenhamer: Fum

Now, here’'s an example when connecting through a connection manager:

: This room is not anonymous.

davidyar: Just that one message though

davidyar: B Message

davidyar: C message

kenhamer: Fie

davidyar: Session #2 Message #3

kenhamer: Fo

davidyar: Yes I can see history

davidyar: Message #2

davidyar: Message #4

davidyar: END Session #1

davidyar: Session #2 Message #1

davidyar: BEGIN Session #2

kenhamer has joined the room.

kenhamer: Foo

kenhamer: Fi

kenhamer: Baz

davidyar: END Session #3

davidyar: Session #1 Message #3

davidyar: Session #2 Message #2

davidyar: Message #3

davidyar: Session #1 Message #1

davidyar: Message #1

kenhamer: Fum

davidyar: A Message

davidyar: Session #1 Message #2

davidyar: BEGIN Session #1

kenhamer: Bar

And another example after leaving and rejoining the room (note the different order):

kenhamer has joined the room.

: This room is not anonymous.

davidyar: Yes I can see history

davidyar: Message #2

davidyar: Message #3

davidyar: B Message

davidyar: C message

davidyar: BEGIN Session #1

davidyar: Session #1 Message #3

davidyar: END Session #1

kenhamer: Bar

kenhamer: Fo

davidyar: Message #4

davidyar: Session #2 Message #2

kenhamer: Fum

kenhamer: Fie

davidyar: Session #2 Message #3

davidyar: Just that one message though

davidyar: Session #2 Message #1

davidyar: END Session #3

kenhamer: Foo

kenhamer: Baz

kenhamer: Fi

davidyar: Session #1 Message #1

davidyar: A Message

davidyar: Message #1

davidyar: BEGIN Session #2

davidyar: Session #1 Message #2

This may or may not be permissible in the Jabber protocol, but it’‘s definitely a bad user experience. While one could argue that clients should reassemble messages in order, the protocol doesn’‘t appear to require that easier and it’‘s unrealistic to expect every client to implement such a thing. So if it’'s possible to address this on the server side (deliver messages in a FIFO manner) then that would be best.

Anyway, it’‘d be nice if we could get this logged in the issue tracker, or get clarification that it’'s already a known issue as it2000 suggested earlier in this thread.

Message was edited by: khamer