在发布者确认模式中唤起nack [英] Evoke a nack in publisher confirm mode

问题描述

在发布者确认模式下发生 Nack 的可能原因是什么?能否可靠地生成 Nack 以进行测试，而无需将电缆拉到磁盘或其他基于硬件的操作?

What are the possible reasons for a Nack to occur in publisher confirm mode, and can a Nack be reliably produced for testing, short of pulling a cable to the disk or other hardware-based actions?

例如发送到不存在的交换不会导致 Nack.它会导致频道关闭，就像在非确认模式下一样.

E.g. sending to a non-existing exchange does not lead to a Nack. It leads to a channel close, just like in non-confirm mode.

顺便说一句，我的兔子集群运行在 Windows 机器上，这可能很重要，因为文件系统的工作方式与 unix 世界中的文件系统完全不同.

Btw my rabbit cluster is running on Windows boxes, which might matter, as the file system works quite differently from those in the unix world.

推荐答案

生成 Nacks 的一种方法是

One way to generate Nacks is to

1. 创建虚拟硬盘
2. 配置环境变量 RABBITMQ_MNESIA_BASE 以指向该驱动器上的文件夹
3. 重新安装 RabbitMQ 服务，以便获取更改的 mnesia 基础目录
4. 重启服务
5. 在排队消息时使虚拟硬盘脱机

1. create a virtual hard disk
2. configure the environment variable RABBITMQ_MNESIA_BASE to point to a folder on that drive
3. reinstall the RabbitMQ service so the changed mnesia base dir is picked up
4. restart the service
5. take the virtual hard disk offline while enqueueing messages

一项测试证实，这实际上会导致 Nack.

A test confirmed that that will actually result in a Nack.

这篇关于在发布者确认模式中唤起nack的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！