本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# `java.util.concurrent.TimeoutException` 疑難排解
<a name="best-practices-gremlin-java-exceptions-TimeoutException"></a>

等待其中一個 WebSocket 連線中的插槽變成可用時，若 Gremlin 請求在客戶端本身逾時，則 Gemlin Java 用戶端會擲回 `java.util.concurrent.TimeoutException`。此逾時持續時間是由 `maxWaitForConnection` 用戶端可設定參數控制。

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

這種逾時通常是由下列兩種方式之一引起：
+ **伺服器實際上已達到容量上限。**若是這種情況，則伺服器上的佇列填滿，您可以監控 [MainRequestQueuePendingRequests](cw-metrics.md#cw-metrics-available) CloudWatch 指標來偵測此佇列。伺服器可以處理的平行查詢數目取決於其執行個體大小。

  如果 `MainRequestQueuePendingRequests` 指標未在伺服器上顯示待定請求的累積，則伺服器可以處理更多請求，而且逾時是由用戶端限流造成的。
+ **請求的用戶端限流。**通常可以透過變更用戶端組態設定來修正此問題。

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

  ```
  maxParallelQueries = maxConnectionPoolSize * Max( maxSimultaneousUsagePerConnection, maxInProcessPerConnection )
  ```

  傳送至用戶端的數目若超過 `maxParallelQueries`，會導致 `java.util.concurrent.TimeoutException` 例外狀況。您通常可採取幾種方式來解決此問題：
  + *增加連線逾時持續時間。*如果延遲對您的應用程式而言並不重要，請增加用戶端的 `maxWaitForConnection` 設定。然後，用戶端會等待更長的時間才逾時，因而增加延遲。
  + *增加每個連線的請求數上限。*這允許使用相同的 WebSocket 連線傳送更多的請求。透過增加用戶端的 `maxSimultaneousUsagePerConnection` 和 `maxInProcessPerConnection` 設定來執行此動作。這些設定通常應該具有相同的值。
  + *增加連線集區中的連線數目。*透過增加用戶端的 `maxConnectionPoolSize` 設定來執行此動作。成本是增加資源耗用量，因為每個連線都會使用記憶體和作業系統檔案描述項，並且在初始化期間需要 SSL 和 WebSocket 交握。