-
-
Notifications
You must be signed in to change notification settings - Fork 353
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
Presence issue in cluster mode #304
Comments
Can you please comment on this? We built one of our functions on the presence events and this behavior makes our algorithm useless. |
Any comments? |
Thanks :) |
I think a cluster does not keep subscribed channels on other clusters. Is that right? |
Anything? |
@postacik sorry have been busy lately. I'll have a look, but by the sound of it it sounds like a bug. I'm thinking that it could be fixed by brokers having a sort of "heartbeat" for presence and if a server goes down others can remove the connection from the presence list and hence send the event. The downside is that you might receive the "disconnect" event multiple times in case of several brokers decide to clean it up at the same time. |
Thanks. Having multiple disconnect events would not be a problem. |
Hi @kelindar , any news about this bug? |
Hi @kelindar , I hope you're well during these quarantine days. Have you had any chance to look at this issue? |
Hi @postacik sorry I've been quite busy these days. Still alive and good, but didn't have much time yet to look into this. |
Thanks, I'll test it asap. |
Hi @kelindar , it seems to be fixed according to my very first tests. We are using the "gobetween" load balancer in front of emitter clusters and trying to build a keep-alive algorithm, monitoring the presence events on a specific emitter channel. Using this algorithm, our application servers will decide which one is primary and which one is backup. Thanks again. |
Hi,
We have a problem with the following scenario:
A is connected to cluster1 and subscribes to "channel/" and also subscribes to presence of "channel/".
B is connected to cluster2 and subscribes to "channel/" and also subscribes to presence of "channel/".
When A disconnects from cluster1, B gets an "unsubscribe" event with the id of A.
But when cluster1 goes down while A is still connected, B does not get an "unsubscribe" event.
Is this behavior by design or is it a bug?
The text was updated successfully, but these errors were encountered: