will trigger controller with @MessageMapping. But in case when there is the second node and other client (different login) will also subscribe to "/user/queue/events" and its session id is the same as on the first node (because names just simple sequences ) The second user will receive the message instead of the first user, because first node created RibbitMQ queue with name "events-user0" and the second node subscribed to the +same+ queue.
The generated unique ids for the WebSocket session or different names for Broker queues can handle this issue.
Thanks for the report, indeed it looks like an issue.
Enabling SockJS, and using a SockJS client with the websocket transport listed as the only transport when connecting, is one potential workaround in the mean time. The SockJS sesssion id is generated by the client using a random seed supplied from the server on the initial "/info" URL. Subsequently when the WebSocket transport is used, the WebSocketServerSockJsSession wrapper uses the SockJS session id and ignores the one from the underlying WebSocket session.