Detail
The proto-fd-idle-ms controls the time a client connection can stay idle before being reaped by the server. The client libraries also have a configuration for closing idle connections (maxSocketIdle for the Java Client Library for example).Following article is applicable for server version 4.8 and above.
Answer
Aerospike version 4.8.0.1 introduces a keep-alive mechanism for client sockets.
In Aerospike versions 4.8.0.1 (and above) server can use keep-alive for client sockets ([AER-6141).
You can now set proto-fd-idle-ms to 0 , this would ensure no reaping of connections on the server side and rely on keep-alive.
The server would rely on TCP keep-alive (IdleTimeout=60 seconds, ProbeInterval=60 seconds, ProbeCount=2) to detect dead sockets.
In latest clients, for example latest java client 4.4.12 (and above) you can also set maxSocketIdle to 0 (CLIENT-1291).
Let's dive into the details of setting the maxSocketIdle in the client policy.
ClientPolicy maxSocketIdle controls the maximum time a socket is allowed to stay in node connection pools.
If maxSocketIdle == 0:
- The cluster tend thread will trim connections down to the min connections configured using a hard-coded max idle time of 55 seconds.
- The transaction thread connections will not be checked for expiration (no reaping in the path of a transaction).
If maxSocketIdle > 0 :
- The cluster tend thread will trim connections down to the configured minimum connections using maxSocketIdle.
- The transaction thread connections will be checked for expiration using maxSocketIdle. This could, in some cases, lead to connection reset errors if a server closed a connection (proto-fd-idle-ms > 0) as the client is attempting to use it. This could happen if the server proto-fd-idle-ms > 0 and proto-fd-idle-ms < maxSocketIdle, or if the tend thread is taking longer than expected to tend all nodes in the cluster.
If the server proto-fd-idle-ms is set to zero, it is a good practice to also set maxSocketIdle to zero. In general, it is suggested to set proto-fd-idle-ms to zero.
The connection is returned back to the pool if the client command finishes with success or for server generated errors. If a client errors during parsing of a response or if a network error occurs, the connection is closed and not put back into the pool.