WebSphere MQ和IIB：活動可能填補隊列管理器

Question

我寫的IIB流是除其他事項外產生事件消息（監視功能）。爲了能夠處理所有這些事件，我需要做一個持久訂閱。但是，如果我這樣做了，並且如果消費應用程序因某種原因不能恢復在線，質量管理可能會填滿並最終停止。 有什麼辦法可以避免這種情況？任何方式來創建一個管理的持久訂閱與「強制消息到期」？

Answer 1

這原來是一個相當常見的情況，但一個可以是具有挑戰性的。的許多方法可能的，這裏有一些常見的：

使用循環隊列
「循環隊列」是不是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修訂包4，IBM還介紹了隊列和主題的CAPEXPIRY屬性。 （見：Enforcing lower expiration times）只需設置它，並忘記它。

自動化隊列清理
使用Q或QLoad程序來搜索比規定時間早消息，並刪除它們。這個安排使用您喜歡的作業調度程序，或使用MQ儀器尋找的東西，如隊列填滿或很長的隊列服務間隔

不要這樣做
持久訂閱是事情是應該到永遠在場或至少可靠地回來。在這些情況下，提供部署訂購併刪除退役流程的隊列部分。如果由於訂戶是臨時的而不存在停用過程，則不要使用持久訂閱。我知道，說起來容易做起來難。

注
我不能肯定這個，因爲我不再像MQ產品團隊的一部分工作，但我懷疑新CAPEXPIRY功能是提供解決這一問題。當IBM引入MQ MFT（以前稱爲FTE的產品）時，Explorer模塊使用永久性動態訂閱來收集文件傳輸作業狀態。然而，很多情況下，我的資源管理器實例忘記了訂閱，人們改變了計算機或工作，或導致放棄訂閱的一千種其他原因。

這不是用於MFT組要求的易溶問題。有利於用戶體驗或有利於高效的系統使用，但不是兩者兼顧現在我們有CAPEXPIRY這些訂閱隊列最終會自行清空。我很快就會預測排隊的排隊隊列將會在哪裏排隊，這樣我們就不會有數十億人被遺棄的空蕩蕩的隊列。

Answer 2

不要讓一個持久訂閱如果有機會，消費應用程序可能永遠不會重新連接。