-
Notifications
You must be signed in to change notification settings - Fork 6
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
Pub/Sub Features #15
Comments
Do you mean that for sharing Session information, or balancing the actual WebSocket connections? Can you be more specific on what you request? |
Load balancing web socket connections was my focus. There comes a time when your server is at capacity or beyond. Either you reject additional connections or ???. The option that many use for websockets is using Redis as the bridge to flow using pub/sub features. |
That sounds more like a task for the proxy server, e.g. the web server if you're using one in front of your servlet container. I'm not sure how implementing that into the extension would be beneficial. |
If it were the traffic you were balancing perhaps. With a websocket the messages have to be distributed to the right people across systems. A proxy server would not be able to effectively distinguish what the client was subscribed to within the cluster. That distribution is what is being done by Redis. Perhaps it needs a different extension but a proxy server is not the answer. |
I think that I understand what you mean now. So you're saying that an incoming message will go to Redis, and then Redis will send that message to all of the subscribers? Or to all of the Lucee servers which will then will send the message to all of the subscribers? |
Right, think about how Slack would work internally. You could not target all the chatter for a channel via a proxy server. Redis lets someone hit the server they hit, and then it subscribes to a channel published on the cluster. Scale becomes much easier. |
I don't have any time to look into this ATM. One solution that I can think of, though might not be as good as the Redis one, is to maintain a list of your Lucee servers, and send the details of an incoming message to them via an http request. Then have those servers send a websocket message to all of their subscribers. |
Thanks for the considerations. We have a month or two to figure this out before it hits our weekly sprint. |
I agree with isapir initial comment, you're mixing infrastructure into apps. The two should be separate. |
Using AWS for example, a load balancer could be configured to send websocket requests to a group of websocket-specific servers in a round-robin fashion based on pattern matching of the request ("/ws/*" requests get routed to the websocket target group). This target group could also be auto-scaled if needed. From my perspective, the big piece that's missing is some sort of messaging system that can broadcast messages to the cluster, like when session data changes (i.e. when a user logs out), in which case the websocket servers could react to those messages and do the right thing. |
Redis is known for clustered scale on Websockets. Do we have this kind of functionality in the Lucee-Websockets? Is there a way to tie these into Redis to serve as the go between in a cluster?
https://redis.io/topics/pubsub
The text was updated successfully, but these errors were encountered: