我正在编写一个 IIB 流，其中包括生成事件消息（监控功能）。为了能够处理所有这些事件，我需要进行持久订阅。但是，如果我这样做了，并且如果消费应用程序由于某种原因没有重新联机，那么 QM 可能会填满并最终停止。 有没有办法避免这种情况？有什么方法可以创建具有“强制消息过期”的托管持久订阅？
【问题讨论】：
标签： ibm-mq messagebroker
事实证明，这是一个相当常见的用例，但也可能具有挑战性。在众多可能的方法中，以下是一些常见的方法：
使用循环队列
“循环队列”不是 IBM 的官方术语，而是我在我的文章 Mission:Messaging: Easing administration and debugging with circular queues 中创造的。循环队列是使用 SupportPac MA01 (now on GitHub!) 中的 Q 程序和 MQ 的本机工具来实现的，以将队列修剪到 MAXDEPTH 的 80%。这是 2011 年发布的，根据我收到的反馈，我猜至少有 100 家商店成功地使用了这种自动化。
使用 MQ v8.0.0.4
从 MQ v8.0 Fix Pack 4 开始，IBM 引入了队列和主题的 CAPEXPIRY 属性。 （请参阅：Enforcing lower expiration times）只需设置它并忘记它。
自动清理队列
使用 Q 或 QLoad 程序搜索早于指定时间的消息并将其删除。使用您最喜欢的作业调度程序来安排此任务，或使用 MQ 检测来查找诸如队列已满或队列服务间隔非常长之类的事情
不要这样做
持久订阅适用于假定始终存在或至少可靠返回的事物。在这些情况下，在部署时提供订阅，并使队列的删除成为退役过程的一部分。如果由于订阅者是临时订阅者而没有停用过程，请不要使用持久订阅。说起来容易做起来难，我知道。
备注
我不能确定这一点，因为我不再是 MQ 产品团队的一员，但我怀疑提供了新的 CAPEXPIRY 功能来解决这个问题。当 IBM 推出 MQ MFT（以前称为 FTE 的产品）时，Explorer 模块使用永久动态订阅来收集文件传输作业状态。但是，在很多情况下，Explorer 实例忘记了订阅、人们更换了计算机或工作，或者其他一千个原因导致订阅被放弃。
对于 MFT 要求集，这不是一个容易解决的问题。偏爱用户体验或偏爱高效的系统使用，但不能两者兼而有之。现在我们有了CAPEXPIRY，这些订阅队列最终会自行清空。我很快就会预测空PERMDYN 队列的队列到期时间，所以我们不会有无数废弃的空队列。
【讨论】：
如果消费应用程序可能永远不会重新连接，请不要将其设为持久订阅。
【讨论】：