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

Clarify how to create scalable WebSocket setup [SPR-11450] #16076

Closed
spring-issuemaster opened this issue Feb 19, 2014 · 4 comments
Closed

Clarify how to create scalable WebSocket setup [SPR-11450] #16076

spring-issuemaster opened this issue Feb 19, 2014 · 4 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Feb 19, 2014

Prashant Deva opened SPR-11450 and commented

our app sends around 300 million msgs a day.
we tried using spring 4's websockets for this using the simple in memory broker.

Even though our heap size was well below 500mb and cpu usage was < 10%, we see that new relic shows an insane amount of time spent in the dispatcher servlet.
all our other transactions are slowed too.

it seems the spring websocket architecture simply doesnt scale and if it does, there is again zero documentation on how to do that.

we can use an external messgaing queue, but it seems that will only impact the memory used for keeping the queue and not much else since the all the messages from the queue are passed back to the client through the app anyway.

It is also unclear if clustering the jvms with an external message queue would help. will the msgs sent back to client subscription be split into multiple jvms?

again no guidance/documentation on any of this. please clarify.


Affects: 4.0.2

Sub-tasks:

  • #16078 Add guidance on scaling when using @EnableWebSocketMessageBroker
  • #16180 Increase default pool size for clientInboundChannel and clientOutboundChannel in WebSocket config
  • #16210 Provide defensive mechanism to prevent slow WebSocket clients from consuming server resources

0 votes, 8 watchers

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Feb 19, 2014

Rossen Stoyanchev commented

update 26/Mar/14: original comment deleted, effectively superseded by the content added to the reference documentation as a result of this request.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Feb 19, 2014

Rossen Stoyanchev commented

I've created documentation sub-task #16078.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 25, 2014

Rossen Stoyanchev commented

This should be a good start. We'll update as necessary over time.

@jaggukaka
Copy link

@jaggukaka jaggukaka commented Oct 12, 2019

Hello,
Looks like it's a pretty old issue. I'm facing exact same issue, I'm using stomp over sockjs with SimpleMessageBroker, Jetty and Spring boot 1.5.9.RELEASE. Whenever there's a client on unreliable network connection with lot of dataflow, the stomp broker doesn't accept new connections, and it doesn't sends data to any existing connections.
Along with above setup there's a non-stomp websocket connection on same server, which connects, sends data as expected.
Issue is only with stomp connections. All existing stomp connections become zombie and no new connections/subscriptions are accepted. All this happens only when one or more clients are on an unreliable connection, this doesn't happen with clean disconnection and re-connection of clients.

I want to know if there is any solution for this or is there any better way to handle this (possibly reactive stack?), is there is any configuration setting that can release resources quickly? any recommendations for clientInbounChannel and clientOutboundChannel configurations?
I'm running on a single server, as the number of websocket/stomp clients won't go beyond 100 or 200. But there's a very good chance the connections from clients will be on unreliable networks. I know scaling server may solve the issue, but I don't know if it's the right approach?
Also want to know if anything changed in srpingboot 2.1.9.RELEASE, as I have upgraded to this version, still need to test in production, I switched to undertow hoping the issue is better handled.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.