当前位置: 首页 > 知识库问答 >
问题:

ActiveMQ Artemis:生产者失败,JMSException AMQ219016

岳良策
2023-03-14

我们有一个ActiveMQ Artemis 2.14.0实例,其中包含队列和生成器,该实例有时会失败,并出现以下错误:

javax.jms.JMSException: AMQ219016: Connection failure detected. Unblocking a blocking call that will never get a response
    at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:467) ~[artemis-jms-client-all-2.14.0.jar!/:2.14.0] 

我们需要了解可能出现这种情况的情况。我们看到这种情况时有发生,也不知道确切的情况。有人经历过这一点并能提供任何解决方案吗?

共有1个答案

吴松
2023-03-14

文档很好地描述了可能引发此异常的原因:

如果客户端代码处于对服务器的阻塞调用中,等待响应以继续执行,则发生故障转移时,新会话将不知道正在进行的调用。否则,这个电话可能会永远挂起,等待一个永远不会到来的响应。

为了防止这种情况发生,Apache ActiveMQ Artemis将通过使故障转移时正在进行的任何阻塞调用抛出javax.JMS.jmsException(如果使用JMS)或带有错误代码ActiveMQException.unblockedActiveMQException来解除阻塞。由客户端代码捕捉此异常并在需要时重试任何操作。

如果被解除阻塞的方法是对commit()prepare()的调用,那么事务将自动回滚,Apache ActiveMQ Artemis将抛出javax.JMS.transactionRolledBackException(如果使用JMS),或者抛出ActiveMQException,错误代码ActiveMQException.transaction_rolled_back,如果使用核心API。

 类似资料:
  • 我有一个生产者/消费者模式,如下所示 固定数量的生成器线程,每个线程写入它们自己的BlockingQueue,通过执行器调用 单个使用者线程,读取生产者线程 每个生产者都在运行一个数据库查询,并将结果写入其队列。消费者轮询所有生产者队列。目前,如果出现数据库错误,生产者线程就会死掉,然后消费者就会永远停留在产品队列中等待更多的结果。 我应该如何构造它来正确处理catch错误?

  • 我们也正在手动更新成功提交后的偏移。KafkaTransactionManager用于维护事务。由于消息是通过RestController发布到firstTopic的,我们的@Transactional从那里开始,在偏移更新时结束。为此,我们使用executeInTransaction()。 Kafka造型 Rest控制器 这是解决生产者失败的正确方法吗? 有没有方法在第10次重试后捕获异常并根据

  • 我正在用Springboot做一个简单的Kafka示例项目,我遇到了一个错误,制作人没有创建,但其余的工作正常。 我遇到的错误似乎引发了异常,因为制作人没有创建,但没有解释原因,我也不知道: 这是我的kafka配置: 这里是控制器,endpoint“/api/kafka”:

  • 问题内容: 我正在通过jenkins部署Ember CLI应用程序,并使用nginx发布它。这是通过詹金斯构建脚本: nginx的配置只是引导到。效果很好,但是当我转到页面时,该页面为空白,并且在控制台中显示以下输出: 我猜这两个错误是相关的,但我不知道是什么导致了它们。我曾尝试这个答案似乎是一个类似的问题,但它并没有为我工作。一切在我的开发环境中都可以正常工作,并且在里面我看不到任何可疑的东西。

  • 我有一个奇怪的错误,当我生成战争与圣杯战争指挥官 我不明白为什么这个文件夹会出现问题。我检查了它,但没有任何可疑之处。我测试清洁没有成功。运行应用程序命令工作。 StackTrace出错 war - stacktrace |正在处理1214的第53个文件-yui application/dial/assets/dial-core . CSS . |错误war打包错误:/Users/so vlin/

  • 我有一个消费者作为生产者消费者模式的一部分: 简化: 如果我移除 通过将线程设置为睡眠,CPU使用率攀升到极高的水平(13%),而不是0%。 此外,如果我实例化该类的多个实例,则每个实例的CPU使用率都会以13%的增量攀升。 大约每分钟(可能每30秒)都会向BlockingCollection添加一个新的LogItem,并将适用的消息写入文件。 有没有可能线程以某种方式阻止了其他线程的运行,而系统