没有连接的 AMQP/RabbitMQ 通道什么时候会死亡？
我有一个简单的 RabbitMQ 测试程序，随机将消息排队，另一个读取它们，所有这些都使用 Spring-AMQP。如果消费者死亡（例如，在没有机会关闭其连接或通道的情况下终止进程），则它尚未确认的任何消息似乎将永远保持未确认状态。
我看过许多参考资料（例如 这个问题），这些参考文献都说通道在没有连接时就会终止，而剩下的通道就会终止。未确认的消息将被重新传送。这不是我看到的行为 - 相反，我得到了越来越多的标记为空闲的通道列表和越来越多的标记为正在运行但没有活动的连接列表。
是否需要进行一些配置才能注意到进程被终止后连接就消失了？
编辑： 我在 VirtualBox VM 中运行rabbitmq 服务器，它显然无法通过 NAT 正确管理无效的入站连接。这对于直接在物理主机上运行的 mq 服务器来说效果很好。
I have a simple RabbitMQ test program randomly enqueuing messages, and another reading them, all using Spring-AMQP. If the consumer dies (for example killing a process without having a chance to close its connection or channel), any messages that it had not acknowledged appear to remain unacknowledged forever.
I have seen a number of references (for example this question) that say that the channel dies when it has no connections, and that remaining unack'd messages will be redelivered. That's not the behaviour I see - instead I get a growing list of channels marked IDLE and a growing list of connections marked running but with no activity.
Is there some configuration required to notice that connections are dead once the process has been killed?
EDIT:
I was running the rabbitmq server inside a VirtualBox VM, which apparently doesn't manage dead inbound connections correctly over NAT. This works just fine with the mq server running directly on the physical host.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
AMQP 使用队列和交换器。您在交换器上发布并绑定队列以从交换器获取消息（您可以查看简短说明 在我的博客上，当您创建队列时，您可以将其设置为自动删除，以及在自动删除之前它会保持未使用的时间。
以下是 RabbitMQ 快速参考中的引用：
AMQP uses Queues and Exchanges. You publish on an exchange and you bind queues to get messages from exchanges (you can see a short explanation on my blog. When you create a queue you can set it to auto-delete as well as how much time will it stay unused before it auto deletes.
Here's a quote from the RabbitMQ quickref:
回答结束。事实证明这不是一个真正的问题。
我在 VirtualBox VM 中运行rabbitmq 服务器，它显然无法通过 NAT 正确管理无效的入站连接。这对于直接在物理主机上运行的 mq 服务器来说效果很好。
Answering to close. This turns out not to be a real issue.
I was running the rabbitmq server inside a VirtualBox VM, which apparently doesn't manage dead inbound connections correctly over NAT. This works just fine with the mq server running directly on the physical host.