在TIBCO EMS（或其他JMS）中，如何創建可擴展的請求/響應處理器？

我正在致力於通過TIBCO EMS提供請求/響應服務的服務器端項目，並且正在尋找關於歸檔可伸縮性以及此服務中的低延遲的最佳實踐的建議。我在.NET上這樣做，但是由於TIBCO EMS被認爲實現了JMS規範，我認爲其他JMS實現和平臺（Java）的建議是相關的。在TIBCO EMS（或其他JMS）中，如何創建可擴展的請求/響應處理器？

當前，我們正在使用一個Connection，一個Session，一個Consumer並在該單個Consumer上使用回調來收聽消息。每個請求在回調線程上進行處理，同時在不同的隊列（但同一會話）上進行回覆。這可行，但看起來並沒有擴展 - 即使在高事務處理速度下，CPU負載也可以忽略不計，但請求延遲不斷增長。

我假設EMS正在爲回調使用單個線程，並且處理時間以及發送回覆所需的時間因此阻止了其他請求被處理，但是 - 什麼是最好的方式讓這個規模？

一種方法是立即安排一旦接收到線程池上的傳入請求的實際處理。這是一個快速解決方案，可以擴展，但會引入額外的延遲，並會在會話使用期間引入線程問題。另一個會有一些會話對象，甚至連接對象？任何人都可以請這樣做的最佳做法建議，我想它一定是在那裏更常見的使用模式之一...

來源

2011-11-01 SoftMemes

你需要一個兩步排隊過程。您的回撥應該儘可能少，而我的首選選項僅僅是將郵件排入本地隊列<T>。然後，可以由多個本地線程訪問此隊列，出列和處理任何可用項目並允許繼續執行JMS排隊過程，從而消除大量延遲。

您需要做一些同步才能將結果返回給正確的消費者，但這應該是相對平凡的。

來源

2011-11-16 11:35:23

如果我使用的客戶端確認模式，我可以使用多個線程來處理消息，並在每個線程上承認處理的消息？ –

消息的處理受確認模式和並行會話計數的影響。

從您的看法來看，聽起來您只使用一個會話並且在處理（和回覆）一個接一個之後確認（客戶端確認）消息。

這可以通過使用自動確認（接收時確認消息）和/或並行使用多個會話來加速。

最重要的是，EMS可以通過一個稱爲「預取計數」的參數來加速消息推送，該參數可以減少從隊列中提取新消息的時間。（請參閱EMS文檔）。

晚的答案，但我希望它幫助;）

來源

2013-03-03 23:38:22 Seb

在TIBCO EMS（或其他JMS）中，如何創建可擴展的請求/響應處理器？

回答

相關問題