[ http://jira.jboss.com/jira/browse/JBREM-786?page=all ] james ahlborn updated JBREM-786: -------------------------------- Attachment: remoting-fixes.txt -- 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

[ 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? -- 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

[ http://jira.jboss.com/jira/browse/JBREM-786?page=comments#action_12387781 ] james ahlborn commented on JBREM-786: ------------------------------------- ah, my bad. i forgot that our library already includes patches backported from the 2.0.0 release, one of which is the flushConnectionPool() addition to the SocketClientInvoker (ported from the MicroSocketClientInvoker). anyway, a little more background on our use case. we are running a service which is getting hit by multiple threads on many different boxes, easily maxing out the connection pool under peak load. this reveals a number of problems in the socket pooling algorithm, which led us to backport code which fixed some of the issues. this patch applies to that backported code, so probably really applies to the 2.0.0 release series. what i think is happening under load, however, is that a socket which is near the end of its useful life is added to the pool after the flush has been called (there's heavy turnover in the pool because of the high load). the socket did not fail for the previous caller, so is not closed, but fails when retrieved from the pool post-flush. this causes the client to run out of retries and fail the call with an EOFException. the changes i made force the client to ignore any pooled connections on the final retry, which solved the problem in our application. -- 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

[ http://jira.jboss.com/jira/browse/JBREM-786?page=comments#action_12393536 ] Ron Sigal commented on JBREM-786: --------------------------------- Unit test: org.jboss.test.remoting.transport.socket.connectionpool.ConnectionPoolRetryTestCase. Restricts number of org.jboss.remoting.transport.socket.ServerThread's to 2 and runs invocations from multiple threads, creating a situation in which ServerThreads are frequently evicted and reused with new sockets, so that there is a high probability that connections in the client side connection pool will be stale. -- 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