导致跳过消息的 Azure 事件中心 ServiceBusException
Azure Event Hub ServiceBusException causing skipped messages
我们正在使用 Azure Java event hub library 从事件中心读取消息。大多数情况下,它运行良好,但我们会定期看到 "com.microsoft.azure.servicebus.ServiceBusException" 类型的异常发生,这些异常对应于事件中心中的消息似乎被跳过的时间。
以下是异常详细信息的一些示例:
- "The message container is being closed (some number here)."
- 这通常会同时命中多个分区,但不是全部。
- 调用堆栈仅包括 com.microsoft.azure.servicebus 和 org.apache.qpid.proton。
- "The link 'xxx' is force detached by the broker due to errors occurred in consumer(link#). Detach origin: InnerMessageReceiver was closed."
- 这通常与 com.microsoft.azure.servicebus.amqp.AmqpException 异常有关。
- 调用堆栈仅包括 com.microsoft.azure.servicebus 和 org.apache.qpid.proton。
示例调用堆栈:
at com.microsoft.azure.servicebus.ExceptionUtil.toException(ExceptionUtil.java:93)
at com.microsoft.azure.servicebus.MessageReceiver.onError(MessageReceiver.java:393)
at com.microsoft.azure.servicebus.MessageReceiver.onClose(MessageReceiver.java:646)
at com.microsoft.azure.servicebus.amqp.BaseLinkHandler.processOnClose(BaseLinkHandler.java:83)
at com.microsoft.azure.servicebus.amqp.BaseLinkHandler.onLinkRemoteClose(BaseLinkHandler.java:52)
at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:176)
at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
at org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:309)
at org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:276)
at com.microsoft.azure.servicebus.MessagingFactory$RunReactor.run(MessagingFactory.java:340)
at java.lang.Thread.run(Thread.java:745)
图书馆的客户似乎没有办法识别问题的发生并避免在事件中心继续我们跳过的消息。还有其他人 运行 参与其中吗?有没有其他方法可以识别并避免跳过或重试错过的消息?
此错误不会跳过任何消息 - 它会在不应该的情况下抛出异常。这将导致 EPH 重新启动受影响的分区的接收器。如果使用 EventHubs javaclient 的应用程序不处理错误 - 它们可能会丢失消息。
这是我们重试逻辑中的错误 - 在 EventHubs JavaClient
的当前版本中 - 直到 0.11.0
。
Here's对应issue跟踪进度。
在 EventHubs 服务中 - 如果 - 由于任何原因 - Container
托管您的 EventHubs 代码 必须关闭 (为了解释起见,假设我们 运行 一组 Container
- 就像每个 EventHub
命名空间的 DockerContainers
) - 这是一个暂时性错误 - 这个 Container
最终将在另一个 [=17] 中打开=].
我们的 javaclient-retry 逻辑应该已经处理了这个错误并且应该已经重试 - 将在这个帖子中发布修复。
编辑
我们刚刚发布了 0.12.0
- 修复了这个问题。
谢谢!
斯里拉姆
我们正在使用 Azure Java event hub library 从事件中心读取消息。大多数情况下,它运行良好,但我们会定期看到 "com.microsoft.azure.servicebus.ServiceBusException" 类型的异常发生,这些异常对应于事件中心中的消息似乎被跳过的时间。
以下是异常详细信息的一些示例:
- "The message container is being closed (some number here)."
- 这通常会同时命中多个分区,但不是全部。
- 调用堆栈仅包括 com.microsoft.azure.servicebus 和 org.apache.qpid.proton。
- "The link 'xxx' is force detached by the broker due to errors occurred in consumer(link#). Detach origin: InnerMessageReceiver was closed."
- 这通常与 com.microsoft.azure.servicebus.amqp.AmqpException 异常有关。
- 调用堆栈仅包括 com.microsoft.azure.servicebus 和 org.apache.qpid.proton。
示例调用堆栈:
at com.microsoft.azure.servicebus.ExceptionUtil.toException(ExceptionUtil.java:93)
at com.microsoft.azure.servicebus.MessageReceiver.onError(MessageReceiver.java:393)
at com.microsoft.azure.servicebus.MessageReceiver.onClose(MessageReceiver.java:646)
at com.microsoft.azure.servicebus.amqp.BaseLinkHandler.processOnClose(BaseLinkHandler.java:83)
at com.microsoft.azure.servicebus.amqp.BaseLinkHandler.onLinkRemoteClose(BaseLinkHandler.java:52)
at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:176)
at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
at org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:309)
at org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:276)
at com.microsoft.azure.servicebus.MessagingFactory$RunReactor.run(MessagingFactory.java:340)
at java.lang.Thread.run(Thread.java:745)
图书馆的客户似乎没有办法识别问题的发生并避免在事件中心继续我们跳过的消息。还有其他人 运行 参与其中吗?有没有其他方法可以识别并避免跳过或重试错过的消息?
此错误不会跳过任何消息 - 它会在不应该的情况下抛出异常。这将导致 EPH 重新启动受影响的分区的接收器。如果使用 EventHubs javaclient 的应用程序不处理错误 - 它们可能会丢失消息。
这是我们重试逻辑中的错误 - 在 EventHubs JavaClient
的当前版本中 - 直到 0.11.0
。
Here's对应issue跟踪进度。
在 EventHubs 服务中 - 如果 - 由于任何原因 - Container
托管您的 EventHubs 代码 必须关闭 (为了解释起见,假设我们 运行 一组 Container
- 就像每个 EventHub
命名空间的 DockerContainers
) - 这是一个暂时性错误 - 这个 Container
最终将在另一个 [=17] 中打开=].
我们的 javaclient-retry 逻辑应该已经处理了这个错误并且应该已经重试 - 将在这个帖子中发布修复。
编辑
我们刚刚发布了 0.12.0
- 修复了这个问题。
谢谢! 斯里拉姆