我们正在将版本从2.5升级到3.0.9,但禁用了websockets。 我们注意到的一个变化是: - org.cometd.server.ServerSessionImpl disconnect()方法不再在消息上设置成功标志,然后将其发布到" / meta / disconnect"渠道。从GitHub cometd存储库注意到它在2015年10月14日作为提交的一部分被删除 - 改进了服务器端断开连接的处理(用户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();
}
}
现在,在客户端,我们使用jquery与cometd(jquery.cometd.js)进行交互。每当我们从服务器端收到cometd断开连接消息时,我们就会发出重新连接。我们在尝试重新连接之前检查以下条件。
$.cometd.isDisconnected() && (message.channel == "/meta/disconnect" && message.successful)
由于更改了断开连接API,message.successful 检查失败,因为它从未在服务器端设置。因此,会话永远不会重新连接/恢复,从而导致服务器根本不知道该会话,因此,服务器端不会将任何服务器推送到客户端服务消息。
我们希望保留此检查,因为在注销期间,此标志已成功设置。在注销时,我们调用下面的客户端方法,这反过来导致服务器端(在BayeuxServerImpl下)的DisconnectHandler被调用。 DisconnectHandler消息事件在回复消息上将此标志设置为true。
$.cometd.disconnect()
首先,想要了解为什么在从服务器端启动断开连接时(不希望它与DisconnectHandler行为一致),不再在cometd断开连接消息上设置成功标志。其次,是否有可能的替代方案仍设置此标志,即可以通过客户端或服务器端的覆盖?
答案 0 :(得分:1)
successful
标志已从服务器端断开连接消息中删除,因为这是未经请求的消息,而不是对客户端发起的断开连接的回复,并且需要区分这两者。
未经请求的邮件没有邮件id
或successful
字段。
如果服务器断开了客户端,并且您想重新连接该客户端,则只需为/meta/disconnect
频道注册一个监听器即可。对于未经请求的断开连接和断开连接回复,将调用侦听器,如果需要,您可以重新handshake()
。