Ibm mq 使用SIGSTOP暂停MQ队列管理器

我有一个简单的IBMMQ应用程序：有2个队列->一个接收队列，显然还有一个是发送队列。现在，我将大量消息放入接收队列，当应用程序处理消息时，我使用SIGSTOP暂停MQ核心进程

消息流应该立即停止吗？我的情况就是这样：

应用程序可以接收所有消息，并在处理后将它们推送到发送队列。现在，如果我尝试将更多消息推送到接收队列中，MQ putter（一个示例实用程序）将无法像通常那样推送消息

我的问题是：在这种情况下，MQ应该如何表现？SIGSTOP信号发出后，信息流是否应立即停止？我的应用程序也没有捕获任何异常

---

任何答案都会有帮助

简单的回答是，没有人能告诉你WMQ在这种情况下应该如何表现，因为天哪，不要这样做

最近有人在列表服务器上问了一个类似的问题。WMQ开发团队的Andrew Hickson这样回答：

向MQ服务器端应用程序发送停止信号是危险的 足够了，但向MQ进程发送停止信号（例如amqrmppa） 这将是极其危险的。如果这个过程发生在国米身上 停止信号到达整个队列时进程锁定 经理很容易就会停滞不前。同样的问题也出现在一个国家 “简单”服务器端应用程序（例如队列管理器范围 在MQCONN处理期间获得/释放锁），但范围 对于无意中停止队列管理器，使用 MQ内部进程

显而易见的问题是，你认为“MQ核心过程”是什么？控制器？代理进程之一？它们都是相互沟通的，没有一个流程代表“QMgr”

---

如果您需要中断处理，请使用WMQ功能，例如禁用队列上的PUT或GET、终止与QMgr的连接等。

我几乎无法让自己达到+1这一点，但如果只有一个人读到它并且没有按照建议做，这将是值得的。我真的不想这样做。但我的委托人正在做什么，并不断寻求解释。对于MQ核心流程，我指的是amqzxma0（来自ps-ef）。对于您的客户机，答案是IBM不建议或不支持针对单个QMgr流程发出SIGSTOP，并且结果是未定义的。好消息是，WMQ非常健壮，能够在这种情况下保持数据完整性，但这并不意味着不可能以这种方式攻击自己。只使用文档化的API和命令，除非得到支持部门的指导。我同意T.Rob。。。这是一件愚蠢的事情…amqzxma0是执行控制器-它几乎是其他事情的协调器-例如，任何连接到qmgr的新进程都需要使用它来分配代理进程。它是EC，它定期检查其他进程的运行状况，或清理一些死掉的进程—暂停它，您就是在自找麻烦。不要这样做…非常感谢！！！还有一个问题。任何人都可以提供指向IBM不建议或不支持针对队列管理器进程发出SIGSTOP的页面的链接吗？很遗憾，我找不到它，没有。一个人可能会对QMgr做无数件坏事，但他们并没有记录所有这些坏事。他们记录下你应该做什么，并假设如果没有记录，你不会尝试去做。