Skip to content
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

Support user destinations with multiple WebSocket servers [SPR-11620] #16243

Closed
spring-issuemaster opened this issue Mar 28, 2014 · 6 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Mar 28, 2014

Max Posner opened SPR-11620 and commented

I have an app, that uses many tomcats. Also it uses websockets. Each tomcat saves in userSessionRegistry some information about connected users. But if user come to tomcat A, other tomcats B, C, D .. don't know about connected users to tomcat A and their unique queue names. And when i trying do something like this:

messageTemplate.converAndSendToUser(userNameConnectedToTomcatA, ...)
from tomacats B,C,D it will not send.


Affects: 4.0.2

Reference URL: http://stackoverflow.com/questions/22371560/spring-websocket-multiple-tomcat-servers/22663838?noredirect=1#22663838

Issue Links:

  • #17529 Investigate possibility of SockJS without sticky sessions

0 votes, 8 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 9, 2015

Rossen Stoyanchev commented

Max Posner, can you confirm if you're using the simple broker or not?

A distributed implementation UserSessionRegistry translating user destinations with awareness of all users should be sufficient in a scenario where a "broker relay" is configured and essentially the broker is shared (I sort of assumed that was the case but I now realize this is not mentioned explicitly). With the simple broker it's also a matter of making sure the message reaches the brokers on all application server instances. This is not a scenario we ever meant to support with the simple broker.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2015

Rossen Stoyanchev commented

Modified title (was "Distributed user sessions") to better reflect the actual goal rather than a possible implementation route.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2015

Rossen Stoyanchev commented

On some further thought, I think there may be a better way.

When a UserDestinationMessageHandler can't resolve a user destination, it can forward the message to a well known topic (e.g. "/topic/unresolved-user-session"). Each "broker relay" would subscribe to this topic and then re-send messages through the local SimpMessagingTemplate which would be checked against the locally known WebSocket sessions. We'd just have to close the loop so that a given message isn't sent to this well known topic again and also prevent anyone (i.e. users) except for broker relays from subscribing to this topic.

That shouldn't be very hard and should be easier to debug than a distributed UserSessionRegistry which would have to keep track of WebSocket sessions on other servers that can come and go quickly (as well as in bulk, e.g. with WebSocket server restarts) creating tricky timing situations. Not to mention that ideally we'd want use Spring Redis which for example abstracts over 4 different Redis libraries (among other benefits) but we can't do that, at least not in the Spring Framework.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 28, 2015

Max Posner commented

sorry, i was unavailable.
yes, i'm using "relay broker"

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 28, 2015

Rossen Stoyanchev commented

Okay, thanks for confirming. That's what we are going to target with this feature.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 17, 2015

Rossen Stoyanchev commented

This is now available in master to try. See the commit for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.