-
Notifications
You must be signed in to change notification settings - Fork 38k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@SendToUser should provide a single session reply mode [SPR-11506] #16131
Comments
Rossen Stoyanchev commented Indeed currently a reply via |
Mark Galea commented Hi Rossen, I have worked out a fix: Can you have a look and see whether it is in line with what you were thinking. If it's ok I'll polish things up and do a pull-request on master. The solution outline is as follows.
Additionally we could also add another reply mode Do you think it would be a possibility to push this fix on version 4.0.3? Obviously there is still some polishing up to do. |
Mark Galea commented One scenario where this kind of semantics would be extremely useful is in scenarios where the underlying broker does not support heartbeats e.g. RabbitMQ. Using the following annotations the client could still send a message to the server and the server could reply to the web socket session directly simulating a heartbeat. |
Rossen Stoyanchev commented Something like The For the ON_HTTP_SESSION mode, the singleSession=false mode is supposed to target all known user session id's as obtained from the configured UserSessionRegistry. Currently we have only a simple implementation of UserSessionRegistry keeping track of user sessions within one application instance. That should work fine. For environments with multiple application instances we could create a Redis-backed UserSessionRegistry implementation in which case you'd be able to target user sessions regardless of which application instance they're connected to. By the way RabbitMQ stomp plugin does have heartbeart support so there is no need to simulate it. |
Rossen Stoyanchev commented By the way do submit a PR. Implementation details can be discussed there and the PR resubmitted if necessary. |
Mark Galea commented Great, I'll open a PR. Regarding the heart beat simulation, you are right RabbitMQ does support the heartbeat however it is currently not supported with sockjs so we are trying to emulate it. Basically we want to be aware of any session disconnections on the client side so that we can re-connect. It would be great if you could share any alternatives on how to achieve this. |
Rossen Stoyanchev commented
All that you need is the RabbitMQ STOMP plugin, i.e. you don't need Rabbit's Web STOMP plugin because you're not connecting directly to Rabbit from the browser and therefore Rabbit's SockJS support is not used here. Instead clients connect to the Spring application via STOMP over SockJS and in turn the Spring application connects to Rabbit and relays messages back and forth. In effect all that Rabbit sees are STOMP over TCP connections from the Spring application. Have you tried it? It works. |
Rossen Stoyanchev commented You can enable TRACE logging for |
Mark Galea commented Thanks for your clarification. Just some clarification on my comment. We encountered an issue when trying to detect when a user has lost connection to the server. Currently there is no way in
In order to detect when the connection is lost we are now registering an
and listen for an error object with the message "Connection to broker closed". A sample of the message follows. In retrospect this makes more sense than what we initially had in mind.
Sorry if my comment was misleading. |
Rossen Stoyanchev commented Yes it should work and it should be transparent. Simply the connection should simply automatically be closed when the server misses a heartbeat. You could also register an onclose or onerror callbacks on the (SockJS) socket. |
Mark Galea commented
Makes sense, actually this was simpler than my initial approach! Thanks! I submitted a pull request here #487 |
Mark Galea commented Rossen Stoyanchev do you think it would be possible to incorporate this fix in the |
Mark Galea opened SPR-11506 and commented
Given a user has two tabs open and the client sends a message to the server from tab 1, it is impossible to send a message to a specific client connection (tab 1). Using the
@SendToUser
("/queue/position-updates") annotation will push the message to both user sessions.Affects: 4.0.3
Reference URL: rstoyanchev/spring-websocket-portfolio#28
Issue Links:
Referenced from: commits c50887c, 75c70fa, 9598a1e, 088b80f
3 votes, 5 watchers
The text was updated successfully, but these errors were encountered: