Connection pool in Aerospike Java Client does not limit number of connections


#1

Aerospike Client Version : 3.1.6 Method : getConnection() Problem : Method get Connection never tracks the number of open connections in the pool. If at any point ‘n’ threads call this method at the same time, and existing queue does not contain any valid connection, all will be returned with a new Connection. Therefore, the property maxThreads is not honored by the client. Please check and explain the reasons for such a design if it is intended.

Code Snippet :

while ((conn = (Connection)this.connectionQueue.poll()) != null) { /* 210 / if (conn.isValid()) { / / try { / 212 / conn.setTimeout(timeoutMillis); / 213 / return conn; / / / / } / / catch (Exception e) / / { / 218 / conn.close(); / 219 / throw new AerospikeException.Connection(e); / / } / / } / 222 / conn.close(); / / } / 224 */ Connection conn = new Connection(this.address, timeoutMillis, this.cluster.maxSocketIdleMillis);


#2

Java client versions 3.2.0+ will enforce max connections.

http://www.aerospike.com/download/client/java/notes.html#3.2.0


#3

Hi Brian,

Thanks for your reply. I checked the linked mentioned and it says below:

Enforce maxConnsPerNode as a hard limit. Return new result code NO_MORE_CONNECTIONS if this limit would be exceeded.

Would this mean client will throw an error if we call get Connection more than configured maxConnsPerNode times parallely. It also does not seem a valid behaviour. It should wait for the connection to be freed in the pool instead of throwing the error.

Please confirm.


#4

Yes, the client throws an exception with result code NO_MORE_CONNECTIONS by design.

One of the complaints about the old soft limit was that there was a silent performance and resource usage penalty when max connections were exceeded.

If the client waited for an available connection, there would be more contention that would again result in a silent performance penalty. The new hard limit is explicit and requires the user to take action.


#5

Thanks Brian for the insights.