Closed yarosman closed 2 years ago
Yes, set WritePolicy.maxRetries to a value greater than zero.
The reason maxRetries defaults to zero for writes is non idempotent writes (such as add()) should never be retried. Write transactions may be performed multiple times if the client timed out previous transaction attempts because the transaction may eventually succeed on the server even on a client socket timeout.
@BrianNichols is it possible to add possibility to retry only ConnectionRefused errors without timeout error? In such case we know that aerospike node doesn't receive request
I doubt internal retries only on java.net.ConnectException will ever be supported.
ConnectException means the server node is down or not reachable. Write transactions are always directed at the key's master node. If the master node is down or not reachable, it's unlikely that retrying on another node will help because that node must still proxy to the master node. An immediate internal retry to the unreachable master node will almost certainly fail again.
You can still perform an external retry on java.net.ConnectException in your application code, preferably waiting some time for the node to recover or for the cluster to reassign the partition to another node.
When we maintain some Aerospike node, on the client side we get ConnectionRefused errors for some period of time for out update request. Is it possible to auto retry all such errors? According to official documentation is suggested to not retry update requests