Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Java Bayeux Client can send a disconnect message without a clientId

See original GitHub issue

I’ve noticed that it’s possible for the Java Bayeux Client to send a /meta/disconnect message without a clientId.

According to the protocol documentation, a /meta/disconnect message must include a clientId.

Steps to Reproduce

  • Ask the client to handshake and then immediately attempt to disconnect.

Expected Result

  • I’d expect the handshake() call to make the client enter into the handshaking session state and send a meta/handshake message.

  • I’d expect the following immediate disconnect() call to make the client enter into either the disconnecting or terminating state and not send a /meta/disconnect message since the client doesn’t yet have a clientId to include in the message.

Actual Result

  • The handshake() call makes the client enter into the handshaking session state and send a meta/handshake message.

  • The following immediate disconnect() call makes the client enter into the disconnecting state and send a /meta/disconnect message without a clientId.

Additional Information

Looking at the code, it’s currently legal for the client to transition directly from handshaking to disconnecting state:

private boolean isUpdateableTo(State newState) {
    switch (this) {
        case DISCONNECTED:
            return newState == HANDSHAKING;
        case HANDSHAKING:
        case REHANDSHAKING:
            return EnumSet.of(REHANDSHAKING, HANDSHAKEN, DISCONNECTING, TERMINATING).contains(newState);
        case HANDSHAKEN:
            return EnumSet.of(CONNECTING, DISCONNECTING, TERMINATING).contains(newState);
        case CONNECTING:
        case CONNECTED:
        case UNCONNECTED:
        case DISCONNECTING:
            return newState == TERMINATING;
        case TERMINATING:
            return newState == DISCONNECTED;
            throw new IllegalStateException();

I wonder if transitioning from handshaking or rehandshaking directly to disconnecting should be an illegal transition. Instead, maybe the client should transition directly to terminating since the client can’t have a clientId when handshaking and may not have a clientId when rehandshaking. (Side note – would it make sense to always clear the clientId before rehandshaking anyway)?

Alternatively, maybe the disconnecting state could skip sending the /meta/disconnect message if the client is coming from handshaking or rehandshaking states. This would likely require updating the documentation for the disconnecting state since it currently implies that a disconnect message will be sent in this state.

* State assumed when the disconnect is being sent

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (2 by maintainers)

github_iconTop GitHub Comments

sbordetcommented, May 22, 2018

CometD API were designed a while ago, and today’s design may be different and more up-to-date with current technologies and patterns.

So if you’re designing new APIs, maybe you want to make sure that handshake() returns something on which you can call disconnect(), so that there is less ambiguity on how to use the API.

Regarding the case at hand, I don’t think the server should disconnect all sessions for a particular BAYEUX_BROWSER if it gets a disconnect without clientId. The current behavior is harmless, in a way: the client will be disconnected, and the server will time out that session - not immediately but eventually that session will be gone.

We may indeed avoid to send the disconnect message, though - it will have the same effect (client disconnected and server timing out the session).

wlisaccommented, May 22, 2018

Makes sense. Thanks again for the help!

Read more comments on GitHub >

github_iconTop Results From Across the Web

BayeuxClient (CometD :: Java 3.1.14 API)
A BayeuxClient can receive/publish messages from/to a Bayeux server, ... Disconnects this session, ending the link between the client and the server peers....
Read more >
Writing my own trivial Bayeux client - Stack Overflow
Connect messages continue to flow between client and server until either side decides to disconnect by sending a disconnect message (a message ......
Read more >
How to catch BayeuxClient error message on cometD client ...
To Simon, what I am trying to achieve is not to disconnect it, but just to hide the message only. I still want...
Read more >
Streaming API, does salesforce server disconnect client after ...
No too much info, only I see is " Cannot connect to bayeux Unknown error: Post EOF 2 2018-Jul-06 ...
Read more >
The Bayeux Specification(Bayeux Protocol -- Bayeux 1.0.0)
A Bayeux client initiates the Bayeux message exchange and will ... The server may not initiate a connection with a client nor send...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found