Context
At times, there could be scenarios where clients connections will be idle and the server keeps reaping those connections. Since establishing new connections are expensive, we may have to delay this reaping.
Assuming no other Client issues and Client connections are just reaping out after being idle you can configure the following setting: proto-fd-idle-ms on the server(s).
This is the time in milliseconds to wait before reaping connections that were initiated by clients. The default is 60 seconds (60,000 ms).
Method
This value can be changed dynamically through use of asinfo to avoid EOF exception or other connectivity issues.
It can be set as low as 1 second:
asinfo -v 'set-config:context=service;proto-fd-idle-ms=1000'
However, when a client disconnects improperly, the connections will remain idle and the server should really reap the connection. In such cases, a higher value could cause the number of connections to go high and potentially reach the maximum allowed. You can increase 'proto-fd-max' but that will increase system resources. Note that the number of connections should be lower than the Operating System set limit (which is set to 100k by default in the Aerospike server installation script). In any case, connections count should be monitored carefully.
Clients can monitor the server statistics via the info API. The related metrics are 'reaped_fds' and 'client_connections'.
Applications can also adjust the idle connections on the client-side. The default is 55 seconds. Ideally, it should be kept to s few seconds lower than the proto-fd-max-ms so clients would close an idle connection first.
In JAVA. modify maxSocketIdle in client policy: https://www.aerospike.com/apidocs/java/com/aerospike/client/policy/ClientPolicy.html#maxSocketIdle
In C, use the function as_async_update_max_idle().