These two configurations are per-request, not end-to-end for an operation. Once a connection is opened, subsequent requests will use the connection.Īn operation started by a user can span multiple network requests, for example, retries. The CosmosClientOptions.OpenTcpConnectionTimeout (or ConnectionPolicy.OpenTcpConnectionTimeout for SDK v2) configuration allows you to set a timeout for the time spent opening an initial connection. The CosmosClientOptions.RequestTimeout (or ConnectionPolicy.RequestTimeout for SDK v2) configuration allows you to set a timeout for the network request after the request left the SDK and is on the network, until a response is received. The SDK has two distinct alternatives to control timeouts, each with a different scope. Are the failures affecting all your application instances or only a subset? When the issue is reduced to a subset of instances, it's commonly a problem related to those instances.Ĭustomize the timeout on the Azure Cosmos DB.
Is the P99 latency / availability affected?.What is the impact measured in volume of operations affected compared to the operations succeeding? Is it within the service SLAs?.When evaluating the case for timeout errors: Your application should have retries in place for timeout errors as these are normally expected in a distributed system. It is important to make sure the application design is following our guide for designing resilient applications with Azure Cosmos DB SDKs to make sure it correctly reacts to different network conditions. The HTTP 408 error occurs if the SDK was unable to complete the request before the timeout limit occurred.
0 kommentar(er)
