Description
Retries
Request to a server may fail and then retried depending on a reason. For example, when connection timeouted it may be retried with same target or next another one.
Policy for retries is application configuration and Java Client should be very flexible in way automatic retries can be configured.
Each retry attempt consumes some time and it may be a problem. For example, application sets maximum execution time and retry attempt take 90% of this limit. In such
case there is no benefit doing a retry attempt. Therefore retry logic should respect any configured time limitations.
This is client feature and feature should be guaranteed by client. If underlying transport has retries mechanism it make sense to limit its use.
Settings
-
com.clickhouse.client.config.ClickHouseClientOption#RETRY "Maximum number of times retry can happen for a request, zero or negative value means no retry."
This setting should be deprecated because it is has too broad meaning. Instead new should be created:- client.max_connection_retries - Maximum number of times a request can be retried if connection initiation error happens.
-
com.clickhouse.client.config.ClickHouseClientOption#MAX_EXECUTION_TIME "Maximum query execution time in seconds, 0 means no limit."
This configuration setting should be respected when checking if retry is needed. -
com.clickhouse.client.config.ClickHouseClientOption#REPEAT_ON_SESSION_LOCK "Whether to repeat execution when session is locked, until timed out(according to 'session_timeout' or 'connect_timeout')."
This options should be kept.
Metrics
- number_of_retries - counter of number of retries per operation type.