一個Java EE服務器可以處理多少個遠程EJB客戶端？

Question

我們遇到的情況是，大約有450個遠程EJB客戶端需要連接到Java EE服務器（OpenEJB 3.1.4容器）。 沒有HTTP服務器。

我們注意到，在使許多客戶端聯機之后，服務器開始引發javax.ejb.ConcurrentAccessTimeoutException。

文檔說這是由於嘗試同時訪問有狀態會話bean或方法中的單例bean超時引起的。 我們實際上同時使用了這兩種方法，但是很難弄清楚超時的好值是多少。

如果該值很高，我們會收到較少的ConcurrentAccessTimeoutExceptions，但是很多客戶端會永遠掛在那里。 如果該值較低，則會引發許多ConcurrentAccessTimeoutException。

所有450個客戶端在啟動時都會建立與服務器的連接（因為連接時間太長，無法按需進行連接）並永遠保持連接。

現在，除此之外，還有另一個問題。 每個客戶端都以2秒的間隔不斷輪詢服務器。 我們可以更改此行為，但是必須調整架構。

是否有研究或任何有很多與Java EE服務器連接的客戶端經驗的人？

我們可以根據需要進行設計，但是我們希望有一個更具體的目標。

Answer 1

在StackOverflow上回答可能是一個棘手的問題，因為最終這是一個與EJB無關的線程問題。 這個問題或多或少與“我有一個在同步塊中執行的代碼，我應該能夠使用多少個線程並保持快速運行？”相同。

真正的問題是同步塊中的代碼在做什么？ （即， @Stateful豆或@Lock(WRITE)的方法@Singleton ）。 目的是消除對同步的需求，或至少縮短同步代碼運行的持續時間。

有獲取此信息的具體方法。

一種技術是將超時增加到無窮大，然后當事情掛起時，在命令行上發出kill -3 12345 ，其中12345是服務器的進程ID。 這將導致線程轉儲被吐到服務器的System.out上。

該輸出將確切顯示每個線程在做什么，我們當前正在調用什么方法，以及該線程是否處於等待狀態。 您將需要多次選擇該輸出。

它應該為您提供一些線索，讓您了解代碼的哪些部分可能最阻礙了演出。 要回答的問題是正在執行的代碼正在導致其他線程不得不等待。