问题标签 [spring-rabbit]

我正在使用一个使用 spring 框架和 rabbitMQ 的应用程序，只要队列中存在数据，它就充当侦听器和出列数据的侦听器。我想要的是侦听器在处理时不能被杀死，它只能在侦听时被杀死并且队列中不存在数据。那么有人对此有任何想法吗？可能吗？如果是，我该怎么办？
谢谢

我正在努力实现这一目标。有很多相互矛盾的答案要知道它是否可能。

根据之前的链接，这是不可能的。但是在这个论坛的另一个问题中，有人说他们可以在这里和在这里的评论部分。

那么，是否可以做实时队列 => 死信队列 => 实时队列

还是我需要使用特定版本的 RabbitMq 来实现这一点？

我能够做到：活队列 => 死信队列和死信队列 => 活队列。

当我关闭 tomcat 时，我在日志中收到这些消息，并且 JVM 没有释放该进程：

我使用调试器查看了这些线程在关闭之前正在做什么，这是它们的线程转储之一：

我用它作为 spring/spring-rabbit 对这个问题负责的证据。

这是我的 Spring 上下文中与 rabbit mq 相关的部分：

当我关闭tomcat时，如何告诉spring-rabbit停止它创建的线程？

我正在使用 spring-rabbit 版本 1.4.2.RELEASE

我正在使用带有 Spring 的RabbitMQ构建一个应用程序：到目前为止一切都很好。为了定义单元测试，我使用了面向外部服务器的 JUnit。我想知道是否有一种方法可以模拟 RabbitMQ 服务器来执行测试，以及是否有多种方法，这是最好的方法。

我发现了一些帖子，但它们是在 2012 年甚至更早之前发布的……也许有一些更新、更简单、更有效的东西！

提前致谢

不确定我在这里缺少什么并且无法搜索解决方案。请帮助解决这个问题。欣赏它。

它在 Jboss EAP 6.3.0 上运行。一旦我启动服务器，日志就会不断滚动，我需要强行停止它。日志在几秒钟内滚动到 20000kb-30000kb

这是 Spring 上下文 xml：

这是 pom.xml 的快照：

编辑：

1. 我删除了架构中的所有版本号。

2. AMQP 版本：

rabbitmq.version 3.1.1

spring.amqp.version 1.1.4.RELEASE

3. 我最近将 webapp (web.xml) 从 2.4 更改为 3.0。那会不会是个问题。在更改之前，我从未测试过它是否有效。这有关系吗？

编辑：下面的这些错误不再出现在错误中。唯一的错误仍然是匹配的通配符

4. 我在日志中看到更多错误（它们不断重复）。这些错误也发生得更早：

(ServerService 线程池 -- 60) JBWEB000287: 向 com.sun.faces.config.ConfigureListener 类的侦听器实例发送上下文初始化事件的异常： java.lang.IllegalArgumentException: JBAS011857: NamingStore is null 在 org.jboss.as.naming.NamingContext.(NamingContext.java:152) 在 org.jboss.as.naming.NamingContext.(NamingContext.java:125) 在 org.jboss.as.naming.InitialContext$DefaultInitialContext.( InitialContext.java:182) 在 org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:117) 在 org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:154) 在 javax.naming.InitialContext .lookup(InitialContext.java:411) [rt.jar:1.7.0_51] 在 javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] 在 com.sun.faces.config .WebConfiguration.processJndiEntries(WebConfiguration.java:702) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] 在 com.sun.faces.config.WebConfiguration.(WebConfiguration.java: 134）[jsf-impl-2.1.28.redhat-3.jar:2.1.28。redhat-3] 在 com.sun.faces.config.WebConfiguration.getInstance(WebConfiguration.java:194) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] 在 com.sun .faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:158) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] at org.apache.catalina.core.StandardContext.contextListenerStart (StandardContext.java:3339) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777 ) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) [jboss- as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] 在 org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] 在 org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java :94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] 在 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471 ) [rt.jar:1.7.0_51] 在 java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java :1145) [rt.jar:1.7.0_51] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] 在 java.lang.Thread.run(Thread .java:744) [rt.jar:1.7.0_51] 在 org.jboss.threads.JBossThread.run(JBossThread.java:122)jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] 在 java .util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] 在 java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7. 0_51] 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] jar:1.7.0_51] 在 java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 在 org.jboss.threads.JBossThread.run(JBossThread.java:122)jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] 在 java .util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] 在 java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7. 0_51] 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] jar:1.7.0_51] 在 java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 在 org.jboss.threads.JBossThread.run(JBossThread.java:122)concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] 在 java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] 在java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7 .0_51] 在 java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 在 org.jboss.threads.JBossThread.run(JBossThread.java:122)concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] 在 java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] 在java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7 .0_51] 在 java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 在 org.jboss.threads.JBossThread.run(JBossThread.java:122)在 org.jboss.threads.JBossThread 的 java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 上运行（ThreadPoolExecutor.java:615）[rt.jar:1.7.0_51]。运行（JBossThread.java:122）在 org.jboss.threads.JBossThread 的 java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 上运行（ThreadPoolExecutor.java:615）[rt.jar:1.7.0_51]。运行（JBossThread.java:122）

和这个：

我正在尝试在队列上设置参数，但是 Spring 的Queue类没有参数的 setter 方法。

http://docs.spring.io/spring-amqp/api/org/springframework/amqp/core/Queue.html

有任何想法吗？谢谢。

在我的项目中，我有一个要求，比如不同的方法将 sql 查询推送到 Rabbit 队列（基本上是一个将消息广播到所有队列的交换器）。与生产相比，此时推送到队列的这些 SQL 查询并不是很重要（基本上用于报告目的），因此当我在服务器上没有太多负载时，我将在不同的环境（其他一些独立项目）中执行这些查询.

现在让我们进入故事的第二部分，在另一端的独立应用程序中有 2 个消费者，它们使用来自 RabbitMQ（交换）的消息（SQL 查询）。一个消费者总是记录（如查询的备份），而其他消费者则在数据库上执行批量更新/插入。

我的问题是什么是实现这个用例的好方法，因为几个原因可能导致少数查询失败，并且因为它是批处理操作，整个批处理将回滚，我无法再次从队列中获取那些已经被消耗的。我知道我必须从我的第二个消费者创建的备份中获取它，但是在遇到任何异常后我必须停止第一个消费者，以及从备份日志中获取特定失败查询的好方法是什么（考虑查询不足，我在想对多日志文件使用滚动附加日志）。感谢您耐心理解我的问题，并请提出解决此问题的好方法。

我有一个似乎是正确配置的 RabbitMQ 队列（显示 dlx 参数），并且在我的 Java 侦听器代码中，我抛出了一个FatalListenerExecutionException. 出于某种原因，在抛出异常后，指定的死信队列中没有显示任何内容。

我是否抛出了错误的异常？

谢谢。

Spring配置中的队列实例化：

Spring 配置中的侦听器容器：

RabbitMQ 控制台中显示的“some.queue”的绑定：

我使用的是 Rabbitmq 客户端 v3.3.4，它有 getReplyQueue() 方法，我用它来消费消息，如下所示：

现在，我将我的 rabbitmq 服务器升级到 3.4.3，所以我决定将 java 客户端库升级到 v3.3.4，但我发现 getReplyQueue() 方法不再存在于 RabbitMQ Java 客户端库中。

在这种情况下，我将如何获得回复队列？

谢谢！

我正在维护一个启动 RabbitMQ 队列的项目上运行一堆测试。据我所知，我没有以任何方式与 RabbitMQ 队列交互。但是，定期，我会得到一个ShutdownSignalException似乎影响我的测试的结果。这是该方法中断点的图像com.rabbitmq.client.impl.AMQConnection#startShutdown：

如何确定我的代码的哪一部分触发了这个异常？另外，我怎么能确信我的代码不使用这个队列？RabbitMQ 代码中是否有任何特殊部分可以设置断点？

我正在使用 Spring RabbitMQ 版本 1.3.5.RELEASE 来配置我的队列。我对 RabbitMQ 了解不多，所以如果我应该提供任何其他信息，请告诉我。