[infinispan-issues] [JBoss JIRA] (ISPN-2699) Failed ping on startup can leave socket dirty

[Galder Zamarreño (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751122#comment-12751122 ] 

Galder Zamarreño commented on ISPN-2699:
----------------------------------------

I see a couple of problems here: 

1. We don't throw any exceptions out of makeObject() is there's any issues with ping() operation. That means both propagating exceptions and other failure conditions. There's no need to check tcpTransport.isValid() because no other thread has used that transport instance, so the socket can't be closed and can't be invalid before it's returned out of makeObject().

2. The server could potentially return a topology if there's any server side error, but the client won't read it unless there was success. This needs some thinking.

What could have happened here is that an exceptional status has been returned and the topology has not been read. To the pool, it would seem that the socket is valid and would therefore return it to another client. The client then sends the request and starts reading the response from the socket and the first thing it'd find is the topology header of the old socket, which would explain the message id mismatch.
                
> Failed ping on startup can leave socket dirty
> ---------------------------------------------
>
>                 Key: ISPN-2699
>                 URL: https://issues.jboss.org/browse/ISPN-2699
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Remote protocols
>    Affects Versions: 5.2.0.Beta6
>            Reporter: Radim Vansa
>            Assignee: Galder Zamarreño
>             Fix For: 5.2.0.Final
>
>
> Ping on startup in TransportObjectFactory.makeObject does not check the return value of ping operation, neither the tcpTransport.isValid().
> Therefore, if a HotRodClientException is thrown when the response header is read from socket, the socket is left in a dirty state.
> In our case this resulted in reading response to previous request (the request was written but the response was not read due to some timeout and then, when another request was executed it read the response to the first request). This caused {{ISPN004004: Invalid message id. Expected 2930 and received 212}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira