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