I tried to replicate issue with message lost when resource conflict happens, however it was not possible using single server. This always worked properly.

During this tests I found that:

• messages are stamped with delayed element with timestamp of detection of broken stream by server

This suggest it was possible that message reported incorrect timestamp

• messages delivery-error element contains proper stamp of message delivery time (first time message was tried to be sent to client connection)

So it is not possible to cause issue with message delivery suggested by report (messages are stamped with time from point 3 - not point 5)

• messages where redelivered after conflict (and after any stream closed caused by server) after resumption timeout passed

It could be related somehow to delivery issue and in case of session being closed (as in case of @conflict@) redelivery of packets should be done without delay

Following changes have been made:

• fixed timestamping of messages in delay element.

• forced redelivery without timeout in case of session being closed (ie. due to @conflict@)

• removed delivery-error element during saving to offline store (this should not change anything but I think this is not needed to be stored to offline store)