[jboss-jira] [JBoss JIRA] Commented: (JBREM-786) stale sockets can be gotten from pool even with current rety logic

[Ron Sigal (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-786?page=comments#action_12387656 ] 
            
Ron Sigal commented on JBREM-786:
---------------------------------

I'm not sure I completely understand this issue.

I suspect that the reason EOFExceptions are appearing is related to some odd behavior in ObjectInputStream.  It seems that once an ObjectInputStream times out, all subsequent readXXX() calls will throw an EOFException, even if the other side is alive and well.   

It's certainly possible for one thread to return a socket to the pool while another socket is trying to extract one.  My question is how timed out sockets are going back into the pool.  A timeout in versionedRead() should result in a SocketTimeoutException, which would be caught by the catch (Exception ex) clause in transport(), which would throw the socket away.

Also, the MicroSocketClientInvoker.flushConnectionPool() method first appears in Remoting 2.0.0, but the 1.4.6.GA is given as the "affects version".

James, if you're listening, could you supply more information?

> stale sockets can be gotten from pool even with current rety logic
> ------------------------------------------------------------------
>
>                 Key: JBREM-786
>                 URL: http://jira.jboss.com/jira/browse/JBREM-786
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.6.GA
>            Reporter: james ahlborn
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>         Attachments: remoting-fixes.txt
>
>
> The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool.  however, this only discards any currently unused scokets.  a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException).  while this seems like an edge case, we can hit it reliably under load with many connections to the same destination.  i've patched this class so that the last call to getConnection will never return a pooled connection.  we never got the EOFException after applying this fix.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira