IBM MQ Connection上的最佳實踐和會話數

我們將IBM MQ用作具有多實例設置的消息傳遞層。使用XMS客戶端（版本7.5）的.NET應用程序將讀取來自多個隊列的消息。由於消息量很大，我爲每個隊列創建了大約5個連接來讀取消息。有4個這樣的隊列。因此，在任何時間點的應用程序中，有20個連接和20個會話都已打開。在此設置下，我面臨兩個問題：IBM MQ Connection上的最佳實踐和會話數

，我常常在兩個XMS例外，同時打開connections.One是MQRC_HOST_NOT_AVAILABLE（（2538，X'9EA'）到對話中分配到遠程系統的嘗試失敗）。另一個是MQRC_CONNECTION_BROKEN（連接到隊列管理器丟失。）
在關閉應用程序時，關閉所有會話和連接需要很多時間，因爲它們太多了。

所以我想減少連接的數量。通過爲每個隊列創建一個連接併爲每個隊列打開5個會話。這樣，連接數將減少到4（從20）。因此，上述兩個問題都將得到解決，我認爲（尚未嘗試）

所以想要知道的人分享他們的經驗，交流上述場景的最佳實踐。與每個連接的單個會話相比，如果我們爲每個連接打開多個會話，那麼傳遞郵件會有延遲嗎？

我正在使用的代碼如下：

private XMSFactoryFactory xMSFactoryFactory; 
private IConnectionFactory connectionFactory; 
private IConnection connectionWMQ; 
private ISession sessionWMQ; 
private IDestination destination; 
private IMessageConsumer messageConsumer; 

xMSFactoryFactory= XMSFactoryFactory.GetInstance(XMSC.CT_WMQ); 
connectionFactory = _xMSFactoryFactory.CreateConnectionFactory(); 
// Set queue manager name, set server names, channel, use 
// XMSC.WMQ_CM_CLIENT as WMQ_CONNECTION_MODE 

connectionWMQ = _connectionFactory.CreateConnection(); 
sessionWMQ = _connectionWMQ.CreateSession(true, AcknowledgeMode.SessionTransacted); 
destination = sessionWMQ.CreateQueue(_queueSettings.QueueName); 
messageConsumer = sessionWMQ.CreateConsumer(_destination); 
messageConsumer.MessageListener = new MessageListener(ProcessNewMessage)

來源

2015-07-20 Ranganatha

您接受了Shashi的答案，這是否意味着您已經解決了問題？如果是這樣，您是否可以留下評論或更新您的問題，以表明該解決方案是爲了未來的Stack Overflow用戶的利益，而這些用戶的搜索將會發布此問答？謝謝！ –

沒有太大的動作發生在連接。它用於創建臨時目的地。會議是所有行動發生的地方。所以只需一個連接即可。

MQRC_HOST_NOT_AVAILABLE和MQRC_CONNECTION_BROKEN可能不是由於您創建的連接/會話的數量所致，因爲隊列管理器可以支持大量連接。

您的應用程序正在使用事務性會話和消息偵聽器。你如何提交交易。你能告訴我們代碼嗎？你是否在爲收到的每條消息調用commit？

來源

2015-07-20 14:47:31 Shashi

是的，Shashi。我正在處理每封郵件。如果不是，我們如何才能進行會議？ if（_queueSettings.UseTransactedSession && _disposed！= true） { _sessionWMQ.Commit（）; } – Ranganatha

正確調整QMgr可以處理數千個連接。 MQRC_HOST_NOT_AVAILABLE表示您碰到資源限制，MQRC_CONNECTION_BROKEN錯誤表明您的會話沒有完全結束並正在成爲孤兒。

不幸的是，沒有足夠的信息來診斷這個與書面的問題。如果我試圖診斷，我想知道的配置設置所有相關的調整參數：

MAXHANDS
SHARECONV
在QMGR最大通道實例設置和渠道
聽者積壓設置
MAXUMSGS
的Keepalive，心跳和其它信道調諧

操作上，我想知道發生這種情況時有多少個通道實例正在運行。

我也想知道在全局錯誤日誌和QMgr的錯誤日誌中看到了什麼錯誤（如果有的話）。

我會查詢未提交的事務並查找錯誤日誌中的回滾事件。如果未處理異常，使用默認調整的QMgr事務回滾可能會導致通道丟失，這不是人們直觀地尋找的。

這些答案可能會導致調整QMgr，增強應用程序或更多診斷，之後我會再試一次。

但是這個問題甚至沒有包含基本的診斷信息，因此無論如何都無法確定根本原因。我可以基於這個問題寫的是，我所做的一件事情是不會做的是試圖通過減少應用程序中的連接數來解決這個問題，因爲20應用程序的合法設計對於任何QMGR。

來源

2015-07-20 17:14:27

IBM MQ Connection上的最佳實踐和會話數

回答

相關問題