Notifications 使用长轮询检索实时通知时是否可能丢失事件？

订阅实时通知时，我会经历正常的握手、订阅、连接流程。 一旦连接返回事件，我重新连接并等待下一个响应返回。我的问题是: 如果在第一次响应和下一次重新连接时生成事件，它们会丢失吗？

例如：同步应用程序在返回后处理返回的响应数据，并且仅在数据处理完成后重新连接，这可能会在响应和下一次重新连接之间造成显著延迟。在该延迟期间生成的积云事件是否缓冲在该特定客户端id的实时队列中，还是只是丢失了

---

另一个可能的例子是，当客户端ID不再有效时（这似乎每天午夜都会发生），我必须重新订阅，导致一段时间内无人订阅

握手连接到服务器端队列时收到的客户端ID。该队列保留在下次连接之前无法接收的所有通知。当你重新连接时，它会传递这些信息。（与邮递员一起尝试：在连接返回后，发送几个事件，然后再次连接。您会注意到，您将一次获得所有事件。）

---

但是，正如您所注意到的，队列不是永远保持的。如果您无法在两小时内重新连接（我相信），队列将被丢弃，以避免阻塞服务器资源。这就是你注意到的。在这种情况下，您需要查询数据库以确定任何错过的事件（例如，从设备轮询处于挂起状态的任何操作）。

因此，当日期更改/午夜时，队列不会自动丢弃，而仅当最后一次连接是在很久以前时才丢弃？是的，这至少应该是一种行为。你有过这样的经历吗？也许cometd中有一个bug？我很乐意使用任何复制机，这样我们就可以潜在地修复它。