2014-05-07 48 views

回答

3

首先,值得注意的是,所提出的設計是一個非常非常糟糕的設計。其效果是將異步消息傳遞迴同步消息。這將消息生成器與消費者相結合,引入位置和解決方案依賴關係,打破集羣,挫敗WMQ的負載分配和平衡,將網絡拓撲嵌入應用程序,並使整個系統變得脆弱。請不要指責WMQ在故意擊敗除實際隊列/出列操作之外的所有最佳功能後無法正常工作。

但是,要直接回答您的問題,請使用隊列對象的getOpenInputCount方法來獲取打開的輸入句柄的數量。方法如下:

MQQueue outQ = qMgr.accessQueue(qName, 
           openOptions, 
           null,   // default q manager 
           null,   // no dynamic q name 
           null);   // no alternate user id 

int inCount = outQ.getOpenInputCount(); 

請注意,您只能查詢本地隊列上的輸入句柄。如果隊列託管在QMgr 其他之上,那麼該方法將不起作用。當然,正常情況下,消息發送者和接收者將駐留在不同的QMgr上。然而,由於你沒有提及設計,所以我將假設這個答案的目的是來自消息生產者和消費者的連接連接到同一個QMgr。如果情況並非如此,我們需要討論PCF,甚至更強烈地警告設計。

+0

感謝您對設計的建議。我正在使用消費者數量作爲觸發器是否在隊列中放置停止消息並停止消耗消息的過程。如果隊列中沒有消費者,則沒有任何可以停止的地方,並且一旦進程重新啓動,放置消息只會導致過早停止。你碰巧有這個java代碼片段嗎? – Mensur

+0

如前所述,通常的方法是將操作/檢測與業務應用程序分開。當隊列深度從零到非零時,WMQ中內置的工具可以啓動應用實例,並且當隊列深度超過預設的高或低閾值時,可以讓WMQ發送控制消息。如果需要更復雜的東西,通常監視或工具守護進程會監視隊列並根據需要啓動/停止應用程序實例。你看過WMQ附帶的代碼示例了嗎? –

+0

我還沒有看到用於Java的MQINQ的任何示例。 – Mensur

相關問題