Reputation: 60
We are upgrading cometd from version 2.5 to 3.0.9 but with websockets disabled. One of the changes we notice is :- org.cometd.server.ServerSessionImpl disconnect() method no longer sets the successful flag on the message, before publishing it to "/meta/disconnect" channel. Noticed from the GitHub cometd repository that it was removed as part of commit on Oct. 14, 2015 - Improved handling of server-side disconnects (user sbordet).
public void disconnect()
{
boolean connected = _bayeux.removeServerSession(this, false);
if (connected)
{
ServerMessage.Mutable message = _bayeux.newMessage();
message.setChannel(Channel.META_DISCONNECT);
// message.setSuccessful(true);
deliver(this, message);
flush();
}
}
Now, on client side, we are using jquery to interface with cometd (jquery.cometd.js). We issue a reconnect whenever we receive a cometd disconnect message from the server side. We check for the below condition before attempting to reconnect.
$.cometd.isDisconnected() && (message.channel == "/meta/disconnect" && message.successful)
message.successful check fails as its never set on the server side due to change to the disconnect API. Hence, the session never gets reconnected / restored, thereby leading the server to not know about this session at all and therefore, server side does not push any server to client side service messages..
We want to retain this check, as during logout, this flag is successfully set.During logout, we call the below client side method which in turn causes the DisconnectHandler on server side (under BayeuxServerImpl) to get invoked. DisconnectHandler message event sets this flag to true on the reply message.
$.cometd.disconnect()
In the first place, want to understand why is the success flag not being set on cometd disconnect message any more, when disconnect is initiated from the server side (would expect it to be consistent with DisconnectHandler behaviour). Secondly, is there a possible alternative to still set this flag i.e. may be through an override either on client or server side??
Upvotes: 1
Views: 899
Reputation: 18597
The successful
flag was removed from the server-side disconnect message because that is an unsolicited message, not a reply to a client-initiated disconnect, and there was the need to differentiate between the two.
Unsolicited messages don't have message id
nor successful
fields.
If the server disconnected a client, and you want to reconnect that client, it is enough that you register a listener for the /meta/disconnect
channel. For both unsolicited disconnects and for disconnect replies the listener will be invoked and you can re-handshake()
if you want.
Upvotes: 1