CometD client (BayeuxClient) state

CometD: 7.0.6

java -version openjdk version “11.0.15” 2022-04-19 LTS OpenJDK Runtime Environment Zulu11.56+19-CA (build 11.0.15+10-LTS) OpenJDK 64-Bit Server VM Zulu11.56+19-CA (build 11.0.15+10-LTS, mixed mode)

Hi,

I was checking the BayeuxClient state in different error scenarios.

When I have error in /meta/connect channel the BayeuxClient returns the following states:

{"clientId":"*****","advice":{"reconnect":"none","interval":0},"channel":"/meta/connect","id":"7","error":"400::Authenticated user id does not match the session's user id","successful":false}

CLIENT STATE isHandshook=false, isConnected=false, isDisconnected=true

Here we are doing a re-handshake, which fails with TimeoutException because of some local environment issue. We receive the error on /meta/handshake channel

{"failure":{"exception":"java.util.concurrent.TimeoutException: Network delay expired: 30000 ms","message":{"ext":{"replay":true},"supportedConnectionTypes":["long-polling"],"channel":"/meta/handshake","id":"8","version":"1.0"}},"channel":"/meta/handshake","id":"8","successful":false} 

This time the BayeuxClient client state is returned as follows: CLIENT STATE isHandshook=false, isConnected=false, isDisconnected=false

This is kind of a state we are not able to make any decision on. I believe the client is doing the re-handshake internally. But if we want to take the control then we need to have a definite state as if the client is already disconnected or not.

Can I request an explanation here? If the client is re-handshaking in the background we need to know that. Also, we need to know in what scenarios the client does the re-handshake on its own.

thanks

[sbordet]

But if subscription fails, ideally the client should fail too. Isn’t it? There is no point of the client being connected but not receiving any message.

No.

The client can look at the subscription failure, and decide to report something to the end user, for example.

That one subscription failed does not mean that the others don’t work.

Imagine you can subscribe to /userChat but you cannot subscribe to /adminChat because you’re not an admin. You still want to receive the /userChat messages so it’s perfectly fine to remain connected.

[dyutiman]

Thanks a lot for clarifying!