Configuring client timeouts
- Thread starter admin
- Start date
Two configuration options in the soss_client_params.txt file (located in the product's installation directory) control a client application's timeout behavior:
max_lcl_retries (or max_rem_retries for clients on remote machines) specifies the maximum number of retries that a client will make to connect to a SOSS server or to retry a request once connected. Values from 0 to 100 are allowed.
max_access_time specifies the maximum time in seconds that a client will use to make an access request to a SOSS server. Values from 0 to 255 are allowed, and a value of 0 disables this parameter. If the maximum access time is exceeded, the current access request is aborted, the client's connection to the server is closed, and an exception is returned to the caller. A client application needs to handle exceptions that could be thrown when the application hits internal thresholds associated with either of these parameters.
The max_lcl_retries and max_access_time parameters do address different problems, but there is some overlap in their behavior.
The max_lcl_retries parameter only controls how many times the client tries to establish a connection to the server. This setting is used to determine how many times a client should try to connect when the service isn't running (or is otherwise unreachable for any reason) before an exception is thrown.
The max_access_time parameter is intended to control the client behavior when the service is up and running but slow to respond. This is for situations where a client thread that is accessing the ScaleOut service must unblock and allow a request to complete within a specified timeframe. It's a potentially dangerous parameter if it's set too low: for example, there may be a large object in the store whose retrieval takes a long time, but a short max_access_time could cut off a perfectly normal retrieval of that large object from the service.
If the service is reachable then max_lcl_retries does not come into play at all.
These two parameters can conflict with each other when the service is unreachable. For example:
max_lcl_retries (or max_rem_retries for clients on remote machines) specifies the maximum number of retries that a client will make to connect to a SOSS server or to retry a request once connected. Values from 0 to 100 are allowed.
max_access_time specifies the maximum time in seconds that a client will use to make an access request to a SOSS server. Values from 0 to 255 are allowed, and a value of 0 disables this parameter. If the maximum access time is exceeded, the current access request is aborted, the client's connection to the server is closed, and an exception is returned to the caller. A client application needs to handle exceptions that could be thrown when the application hits internal thresholds associated with either of these parameters.
The max_lcl_retries and max_access_time parameters do address different problems, but there is some overlap in their behavior.
The max_lcl_retries parameter only controls how many times the client tries to establish a connection to the server. This setting is used to determine how many times a client should try to connect when the service isn't running (or is otherwise unreachable for any reason) before an exception is thrown.
The max_access_time parameter is intended to control the client behavior when the service is up and running but slow to respond. This is for situations where a client thread that is accessing the ScaleOut service must unblock and allow a request to complete within a specified timeframe. It's a potentially dangerous parameter if it's set too low: for example, there may be a large object in the store whose retrieval takes a long time, but a short max_access_time could cut off a perfectly normal retrieval of that large object from the service.
If the service is reachable then max_lcl_retries does not come into play at all.
These two parameters can conflict with each other when the service is unreachable. For example:
- If the service is unreachable and the client is spinning through its retries (as defined by max_lcl_retries), but those retries take more than max_access_time to complete, the max_access_time threshold will cut short the retry behavior and throw an exception.
- If the service is unreachable and the client has exhausted all of its retries, an exception will be thrown prior to the time specified by the max_access_time parameter.