Bug 1312185 - [GSS](JDG 6.x) Double invalidate of invalid Hot Rod connections
[GSS](JDG 6.x) Double invalidate of invalid Hot Rod connections
Status: VERIFIED
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan (Show other bugs)
6.4.1,6.5.0,6.6.0,6.5.1
Unspecified Unspecified
unspecified Severity unspecified
: ER1
: 6.6.1
Assigned To: Tristan Tarrant
Martin Gencur
:
Depends On:
Blocks: 1309749 1324651
  Show dependency treegraph
 
Reported: 2016-02-25 21:54 EST by dereed
Modified: 2016-08-11 05:04 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker ISPN-6275 Major Closed Double invalidate of invalid Hot Rod connections 2016-09-08 12:40 EDT
JBoss Issue Tracker JDG-82 Major Verified Avoid invalidating transport twice 2016-09-08 12:40 EDT

  None (edit)
Description dereed 2016-02-25 21:54:06 EST
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.
Comment 1 dereed 2016-02-25 21:54:28 EST
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);
Comment 4 Shay Matasaro 2016-02-29 15:03:00 EST
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
Comment 6 JBoss JIRA Server 2016-03-16 11:16:01 EDT
Galder Zamarreño <galder.zamarreno@redhat.com> updated the status of jira ISPN-6275 to Coding In Progress
Comment 7 JBoss JIRA Server 2016-04-04 12:34:04 EDT
Sebastian Łaskawiec <slaskawi@redhat.com> updated the status of jira ISPN-6275 to Closed
Comment 8 JBoss JIRA Server 2016-04-14 09:40:20 EDT
Galder Zamarreño <galder.zamarreno@redhat.com> updated the status of jira JDG-82 to Resolved

Note You need to log in before you can comment on or make changes to this bug.