When there's a problem with a Hot Rod operation, RetryOnFailureOperation invalidates the connection twice (once in a catch block, and once in a finally block). This causes the GenericKeyedObjectPool counts to get off, and anything relying on that count (such as the maxTotal configuration for the pool) to break.
org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation public T execute() { ... try { transport = getTransport(retryCount, failedServers); return executeOperation(transport); } catch (TransportException te) { ... if (transport != null) transportFactory.invalidateTransport(te.getServerAddress(), transport); ... } finally { releaseTransport(transport); } ... protected void releaseTransport(Transport transport) { if (transport != null) transportFactory.releaseTransport(transport); } org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory: public void invalidateTransport(SocketAddress serverAddress, Transport transport) { ... pool.invalidateObject(serverAddress, (TcpTransport) transport); public void releaseTransport(Transport transport) { TcpTransport tcpTransport = (TcpTransport) transport; if (!tcpTransport.isValid()) { ... pool.invalidateObject(tcpTransport.getServerAddress(), tcpTransport);
the impact of this issue for this customer is that more sockets then expected are getting created and using more memory , which results in server stability issues
Galder Zamarreño <galder.zamarreno> updated the status of jira ISPN-6275 to Coding In Progress
Sebastian Łaskawiec <slaskawi> updated the status of jira ISPN-6275 to Closed
Galder Zamarreño <galder.zamarreno> updated the status of jira JDG-82 to Resolved
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.