Fix clustering #511

New issue

Open

opened 2026-05-31 01:30:10 -07:00 by scion · 2 comments

scion commented

2026-05-31 01:30:10 -07:00

Owner

The SessionAttributeService uses a local Map and doesn't actually use the Hazelcast Map which shares information across nodes. So it's likely that in a multi-server situation you couldn't actually interact with players on other members of the cluster.

The `SessionAttributeService` uses a local Map and doesn't actually use the Hazelcast Map which shares information across nodes. So it's likely that in a multi-server situation you couldn't actually interact with players on other members of the cluster.

scion added the

bug

label

2026-05-31 01:30:10 -07:00

scion self-assigned this

2026-06-02 17:16:20 -07:00

scion commented

2026-06-02 17:17:25 -07:00

Author

Owner

It seems to have something to do with headers being stripped by RabbitMQ, or maybe the messages being dropped entirely.

Got the Hazelcast map set up so that all servers can share attributes with each other, but there are some other problems. For example you can't talk to people on the other server, they don't see your movement, and only one server sees weather messages. It seems to have something to do with headers being stripped by RabbitMQ, or maybe the messages being dropped entirely.

scion commented

2026-06-03 09:40:22 -07:00

Author

Owner

This appears to be a bug in Spring, caused by the fact that I'm logged in with the same OAuth account on both servers. In UserDestinationMessageHandler it checks the local sessions to see if the user is listed, and broadcasts to the other servers if it is not. Later, it tries to look up the websocket session to deliver the message to, but if it can't find it it just drops the message. In my particular scenario the same user is logged in on both servers but the correct session is on the other one. It never broadcasts because it found my user, but it never delivers a message because the local user session is the wrong one. This is really unfortunate for me being able to test whether the clustering works but it's also such an edge case that I think I'm going to call it and move on to other things.

This appears to be a bug in Spring, caused by the fact that I'm logged in with the same OAuth account on both servers. In `UserDestinationMessageHandler` it checks the local sessions to see if the **user** is listed, and broadcasts to the other servers if it is not. Later, it tries to look up the websocket session to deliver the message to, but if it can't find it it just drops the message. In my particular scenario the same user is logged in on both servers but the correct session is on the other one. It never broadcasts because it found my user, but it never delivers a message because the local user session is the wrong one. This is really unfortunate for me being able to test whether the clustering works but it's also such an edge case that I think I'm going to call it and move on to other things.

scion added the

wontfix

label

2026-06-03 09:40:40 -07:00

scion referenced this issue

2026-06-03 09:48:36 -07:00

hazelcast-fix #515