Handling timeouts
The SDK supports configuration options to control the various timeouts that application developers may wish to override so that they can fine-tune their applications.
Internally the client uses a set of heuristics and accompanying logic to determine whether or not to retry operations if they fail with a timeout or to return a failure message to the calling application. In general, an application should not provide additional logic in the case that a timeout error is returned; however, it’s likely an indication that the application configuration may be in need of ‘tuning’ or that perhaps a broader system or network level issue may be at play.
Client Timeout Configuration
The following time-out’s are configurable either through the App.Config/Web.Config or through the ClientConfiguration object itself:
| Name | Description | Default |
|---|---|---|
| OperationTimeout | The amount of time to wait on a binary operation before timing out. | 2500ms |
| ViewTimeout | The amount of time to wait on a View query before timing out | 30000ms |
| QueryTimeout | The amount of time to wait on a N1QL query before timing out | 30000ms |
| WaitTimeout | The amount of time to wait for an available TCP connection before timing out | 2500ms |
| ObserveTimeout | The amount of time to spend waiting for an Observe operation to meet it’s durability requirements before timing out | 500ms |
| ShutdownTimeout | The time between when the SDK closes a TCP connection and when it actually shuts down | 10000ms |