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

Unable to fully disconnect remote sessions when broadcastToPublisher is false #835

Open
nathklei opened this Issue Mar 5, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@nathklei
Copy link
Contributor

nathklei commented Mar 5, 2019

In testing I've found that when I disable broadcastToPublisher - which I'd like to do for my application - I'm no longer able to disconnect remote sessions from the BayeuxServer.

I've traced the reason to ServerSessionImpl#disconnect, which removes the session from the server, then attempts to send the disconnect message to the client. However, it uses the same session to do the delivery, which ends up being a no-op because the first condition in ServerSessionImpl#deliver1 triggers.

Ideally there'd be an option to get this to work - potentially by sending the disconnect message from another session on the server. My use case is to disconnect all remote peers from my server based on an application event (in this case, log out from an external system).

I'm including a PR that demonstrates the failure.

nathklei pushed a commit to nathklei/cometd that referenced this issue Mar 5, 2019

Nate Klein
Issue cometd#835 - Change broadcast to publisher test to disconnect v…
…ia server session

Signed-off-by: Nate Klein <nklein@palantir.com>
@nathklei

This comment has been minimized.

Copy link
Contributor Author

nathklei commented Mar 5, 2019

demonstrates test failing when flag is false, but succeeds when true: https://github.com/cometd/cometd/pull/836/files

@sbordet

This comment has been minimized.

Copy link
Member

sbordet commented Mar 5, 2019

Looking at this, thanks for reporting.

@sbordet

This comment has been minimized.

Copy link
Member

sbordet commented Mar 5, 2019

@nathklei so the issue is more complicated than I expected.

The problem is that a server-side disconnect needs to send an unsolicited message to the client.
If the /meta/connect is outstanding, that is simple: queue the disconnect message, wake up the /meta/connect, deliver both, done.

However, if the /meta/connect is not outstanding, we don't have (in general) a mean to deliver the message back to the client: we would need to wait for the next /meta/connect from the client.
Currently we don't wait: we just remove the session from the server, and the next /meta/connect will see an error 402::unknown_client (with an advice to handshake again) because the session has been removed.

Keeping around disconnected sessions until the next /meta/connect arrives does not seem a good strategy (what if it does not arrive?).
I'll think some more about this, but it may be complicated or a "best effort" attempt.

If you really need to send a "disconnect" to the clients, it's probably best and more reliable to do this via an application message, and then a client-side disconnect.
Would that work for you?

@nathklei

This comment has been minimized.

Copy link
Contributor Author

nathklei commented Mar 5, 2019

@sbordet thanks for looking into this. I actually think a best effort attempt is OK in my case. I can look into an application event rather than using the built-in disconnect - though doing this server-side is nice because I have both java and javascript clients and I'd rather not write that logic twice.

I should mention I ended up using a really basic "solution" to the problem in my own code, like

if (serverSession instanceof ServerSessionImpl) {
    ((ServerSessionImpl) serverSession).setBroadcastToPublisher(true);
}
serverSession.disconnect();

Essentially I always set the flag to true, regardless of what it was set to, then immediately disconnect.

Could we do that internal to disconnect() of ServerSessionImpl? Or are there issues with that approach more generally?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.