Askar Ibragimov opened SPR-15528 and commented
Problem
When core pool size of ClientOutboundChannel is >1, race condition happen and message order gets mixed. See http://stackoverflow.com/questions/29689838/sockjs-receive-stomp-messages-from-spring-websocket-out-of-order
Many applications would however desire the orderly propagations of the messages so client is guaranteed to get these in order.
However, for high load servers it is not worthwhile using just one thread. Additionally, Jetty has a problem: its timeout for websocket blocking write operation is set to infinity so if a client never respons with TCP acknowledgement, the tread gets blocked (https://github.com/eclipse/jetty.project/issues/272). So if you are sending messages in order, using one thread, and it gets blocked, your whole server just stops working. This clearly limits the capabilities of Spring's websocket applications.
Solution
Implement an improved version of Executor channel that only allows next message for a session to be propagated when the previous message has been sent. This also allows to detect slow clients and cut these off based on some policy.
1 votes, 2 watchers
Comment From: snicoll
Doesn't setPreservePublishOrder suit your need?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.