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

Users logged in to multiple servers do not get messages in sessions on remote servers [SPR-13800] #18373

Closed
spring-projects-issues opened this issue Dec 16, 2015 · 2 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Dec 16, 2015

Stuart Greenlees opened SPR-13800 and commented

It looks like there may be an issue in the spring-messaging MultiServerUserRegistry class. We have a spring boot application (version 1.3) that uses websockets (spring-websocket 4.2.3 and spring-messaging 4.2.3) and runs in Pivotal Cloud Foundry scaled across a number of jvms. We are using a rabbitMQ backend stomp Broker. When our application is deployed a user may have multiple browser sessions which could potentially be distributed across multiple server instances using the same security Principal. When the application uses convertAndSendToUser to send a targeted message to the user we want that message to go to all browsers that the user has open. However what we are finding is that the websocket user from the server that is processing the message is overwriting the websocket user from other servers. This means that if the user has a websocket connection using the same security principal on two of the servers then the message will only be delivered to one browser.

Here is the code from MultiServerUserRegistry were the overwrite occurs:

@Override
public Set<SimpUser> getUsers() {
     Set<SimpUser> result = new HashSet<SimpUser>(this.localRegistry.getUsers());
     for (UserRegistryDto registry : this.remoteRegistries.values()) {
          result.addAll(registry.getUsers().values());
     }
     return result;
}

The attached sample application https://github.com/stuartgreenlees/springboot-websocket-multiserver (based on the Spring Websocket getting started guide) demonstrates the issue. If you start 2 instances of the application and log into server A with the users ‘mike’ and ‘jim’ and create a websocket connection for both, then hitting the /userssessions endpoint on both servers will show that websocket users for both ‘mike’ and ‘jim’ are visible on both servers. If you then log into server ‘B’ as ‘mike’ then only the user belonging to mike on the current server is visible not both.


Affects: 4.2.3

Reference URL: https://github.com/stuartgreenlees/springboot-websocket-multiserver

Issue Links:

Referenced from: commits 6aa216a, 68f6cf9

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Indeed at present if a user is connected to the local server, the UserDestinationMessageHandler does not forward the message to other servers. We could change that either always forwarding or perhaps checking first through the UserRegistry if the user is connected to other servers.

For that we'd need to make some changes in the MultiServerUserRegistry. As you pointed out getUsers returns a set, which I think still makes sense (after all a user, connected to any server, is the same user still) but that user should contain all sessions on all servers, not just the local server sessions, along with some way of telling them apart (local vs remote).

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

There is a fix for this in master commit 68f6cf (4.3.0 snapshot). I've verified the fix with the attached sample application. Thanks for reporting this and for the test app!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants