java.util.concurrent.TimeoutException 疑難排解

Gemlin Java 客戶端在等待其中一個 WebSocket 連接中的插槽變為可用java.util.concurrent.TimeoutException時，Grimlin Java 客戶端會拋出一個 Gimlin 請求超時。此逾時持續時間是由 maxWaitForConnection 用戶端可設定參數控制。

注意

因為在用戶端逾時的請求永遠都不會傳送至伺服器，所以它們不會反映在伺服器中擷取的任何指標中，例如 GremlinRequestsPerSec。

這種逾時通常是由下列兩種方式之一引起：

• 伺服器實際上已達到容量上限。如果是這種情況，伺服器上的佇列就會填滿，您可以透過監視指標來偵MainRequestQueuePendingRequests CloudWatch 測該佇列。伺服器可以處理的平行查詢數目取決於其執行個體大小。

  如果 MainRequestQueuePendingRequests 指標未在伺服器上顯示待定請求的累積，則伺服器可以處理更多請求，而且逾時是由用戶端限流造成的。

• 請求的用戶端限流。通常可以透過變更用戶端組態設定來修正此問題。

  用戶端可以傳送的平行請求數目上限，可以大致估計如下：

  maxParallelQueries = maxConnectionPoolSize * Max( maxSimultaneousUsagePerConnection, maxInProcessPerConnection )

  傳送至用戶端的數目若超過 maxParallelQueries，會導致 java.util.concurrent.TimeoutException 例外狀況。您通常可採取幾種方式來解決此問題：

  • 增加連線逾時持續時間。如果延遲對您的應用程式而言並不重要，請增加用戶端的 maxWaitForConnection 設定。然後，用戶端會等待更長的時間才逾時，因而增加延遲。

  • 增加每個連線的請求數上限。這允許使用相同的 WebSocket 連接發送更多請求。透過增加用戶端的 maxSimultaneousUsagePerConnection 和 maxInProcessPerConnection 設定來執行此動作。這些設定通常應該具有相同的值。

  • 增加連線集區中的連線數目。透過增加用戶端的 maxConnectionPoolSize 設定來執行此動作。成本會增加資源消耗，因為每個連線都使用記憶體和作業系統檔案描述元，並且在初始化期間需要SSL和 WebSocket握手。