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

[spring-projects-issues]

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:

• Investigate possibility of SockJS without sticky sessions [SPR-12936] #17529 Investigate possibility of SockJS without sticky sessions

0 votes, 8 watchers

[spring-projects-issues]

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-projects-issues]

Rossen Stoyanchev commented

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

[spring-projects-issues]

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-projects-issues]

Max Posner commented

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

[spring-projects-issues]

Rossen Stoyanchev commented

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

[spring-projects-issues]

Rossen Stoyanchev commented

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