问题标签 [bayeux]

I didn't find any promising answer to Multiple Endpoints may not be deployed to the same path though scouring through several stackoverflows and google groups cometd related topics.

Cometd Version: 3.0.5 Tomcat Version: 7.0.55

BayeuxServer instance is created as follows for Spring integration.

Example: https://github.com/cometd/cometd/blob/master/cometd-java/cometd-java-oort/src/test/java/org/cometd/oort/spring/OortConfigurator.java

During this setup cometd and tomcat both tried to add end point on the same path as seen in error log.

Caused by: java.lang.RuntimeException: javax.websocket.DeploymentException: Multiple Endpoints may not be deployed to the same path [/cometd] at org.cometd.websocket.server.WebSocketTransport.init(WebSocketTransport.java:93)

Jul 30, 2015 4:35:02 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet cometd javax.websocket.DeploymentException: Multiple Endpoints may not be deployed to the same path [/cometd] at org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:207)

I understand the cometd doesn't play well with tomcat. Can the tomcat be prevented from adding the end point same as created by cometd? I have a requirement to deploy the application in tomcat.

我正在尝试了解 Bayeux 协议。我还没有找到详细解释bayeux 客户端在技术上如何工作的网络资源。

从这个资源，

Bayeux 协议要求新客户端发送的第一条消息是握手消息（在 /meta/handshake 通道上发送的消息）。

客户端处理握手回复，如果成功，则在后台启动与服务器的心跳机制，通过交换连接消息（在 /meta/connect 通道上发送的消息）。

这种心跳机制的细节取决于使用的客户端传输，但可以看作是客户端发送连接消息并在一段时间后等待回复。

连接消息继续在客户端和服务器之间流动，直到任何一方决定通过发送断开连接消息（在 /meta/disconnect 通道上发送的消息）来断开连接。

我已经用 Java 方法编写了首先进行握手，然后订阅特定频道的方法。我利用 Apache HttpClient 库来执行 HTTP POST 请求。

现在是连接部分。

我的理解是，我需要保持对bayeux服务器的请求，并且每当我收到响应时，都会发出另一个请求。

我已经写了下面的代码。我的理解是否正确，这个bayeux客户端是否表现出正确的连接功能？（请忽略缺少的断开连接，取消订阅方法）

此外，我已经针对bayeux 服务器测试了代码并且它可以正常工作。

我正在开发一个我正在实现聊天功能的 Android 应用程序。考虑到 Cometd 的使用，聊天速度非常快，但出于某种原因，Cometd 正在发送替代消息。如果它发送 message-1，它不发送 message-2，然后发送 3，以此类推。这是一种非常奇怪的行为，并且由于没有错误，因此很难隔离问题。

我添加了系统日志来检查是否调用了 onClick 方法以及发送消息的循环。此外，我在服务器端代码中添加了一个 system.out，并且只接收到备用消息。这导致了 Cometd 以某种方式没有发送所有替代消息的结论。你能帮忙的话，我会很高兴。谢谢你。

请注意，PUSH 服务由 Cometd 提供，它在 ConsoleChatClient.java 中实例化

代码 ：

控制台聊天客户端：

带计数器的代码：计数器初始化为 0。

计数器的服务器端打印：

安卓日志：

服务器端日志：

日志图像：

得到

所以我的第一个猜测是添加授权标头。我怎样才能做到这一点？Jetty 9 用于服务器和客户端代码库。

Is there any chance that things like WebSockets, the Bayeux protocol, or long polling techniques, in general, could be used as a source of events to trigger AWS Lambdas? (without implementing an EC2-based listener)

我们作为客户端的应用程序需要订阅一个外部系统，该系统使用 cometd 向客户端发送未经请求的通知。有没有办法在没有彗星库的情况下实现这一点（例如通过 apache HttpClient）？Java 版本不匹配是问题 - 我们使用 1.6，但 Cometd 需要 1.7 或更高版本。

提前致谢

在文章http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html中作者描述：

通常使用 PubSub，开发人员觉得需要为每个用户创建一个频道，以便将私人消息传递给客户端。例如，如果交易系统想要通知用户完成的交易，很可能会创建一个类似 /trades/a_user_id 的频道，每个用户都将订阅他们自己的频道。这种方法有效，但不是解决此问题的最节省资源的方法，并且需要安全代码来防止未经授权的客户端订阅其他用户频道。

为特定用户实现消息的服务和广播通道之间的权衡是什么？我了解权衡的安全方面，但是资源开销呢？我不明白为什么广播频道使用的资源比自定义路由服务使用的资源多。如果你能解释为什么一个用例比另一个更好，而不是笼统地声明是否明智，那可能有助于我做出决定。

只是为了确保我正确地做到了这一点。我正在编写一个 Bayeux 客户端以与外部 CometD 服务器合作（通过长轮询）。我的客户端按以下顺序发送请求：握手、连接、订阅、连接。后一个连接会停止，直到有消息可用。当消息到来时，服务器响应。一切正常。我做得对吗？

我正在尝试向在 Jetty 9 下运行的 CometD 服务器发送一条大消息（>130k）。当服务器收到这条大消息时，它会生成以下异常：

我了解问题所在，并查看了 CometD 文档。根据文档，您可以使用初始化参数更改缓冲区大小和最大消息大小：ws.bufferSize 和 ws.maxMessageSize。我在 web.xml 文件中设置了这些参数并重新启动了 Jetty，但参数设置似乎没有效果。我仍然得到完全相同的异常，因为缓冲区大小保持不变。

下面提供了 web.xml 文件的设置：

我错过了什么吗？如何在 CometD 服务器中设置最大消息大小并让服务器实际使用该消息大小？

我们正在将 cometd 从版本 2.5 升级到 3.0.9，但禁用了 websockets。我们注意到的变化之一是：- org.cometd.server.ServerSessionImpl disconnect() 方法不再在消息上设置成功标志，然后将其发布到“/meta/disconnect”通道。从 GitHub cometd 存储库中注意到，它在 2015 年 10 月 14 日作为提交的一部分被删除 - 改进了服务器端断开连接的处理（用户 sbordet）。

现在，在客户端，我们使用 jquery 与 cometd (jquery.cometd.js) 交互。每当我们收到来自服务器端的 cometd 断开连接消息时，我们都会发出重新连接。在尝试重新连接之前，我们会检查以下情况。

message.successful检查失败，因为由于断开连接 API 的更改，它从未在服务器端设置。因此，会话永远不会重新连接/恢复，从而导致服务器根本不知道此会话，因此服务器端不会将任何服务器推送到客户端服务消息。

我们希望保留此检查，因为在注销期间，此标志已成功设置。在注销期间，我们调用下面的客户端方法，这反过来会导致服务器端（在 BayeuxServerImpl 下）的 DisconnectHandler 被调用。DisconnectHandler 消息事件在回复消息上将此标志设置为 true。

首先，想了解当从服务器端发起断开连接时，为什么不再在 cometd 断开连接消息上设置成功标志（希望它与 DisconnectHandler 行为一致）。其次，是否有可能的替代方法仍然设置此标志，即可以通过客户端或服务器端的覆盖？