I think I have spotted a bug in Remoting 2.0.
I believe you're right.
Having investigated the code I have found that if a client waits for some time so long as server times out the connection and closes the socket, remoting client gets the very same socket from the pool, incresing usedPooled by one.
I'm not sure how this scenario can occur. If the parameter "socket.check_connection" is configured to "false", then the server shouldn't time out a socket (unless it's in the middle of processing an invocation). If it is configured to "true", then getPooledConnection() should see that the connection isn't functional and shouldn't return the socket. Is it possible that you have "socket.check_connection=true" on the server and "socket.check_connection=false" on the client? This inconsistency could occur if you configure the Connector in a service.xml file:
<mbean code="org.jboss.remoting.transport.Connector" name="jboss.messaging:service=Connector,transport=socket" display-name="Socket transport Connector"> <attribute name="Configuration"> <config> <invoker transport="socket"> ... <attribute name="socket.check_connection" isParam="true">false</attribute> ... </invoker>> </config> </attribute> </mbean>
but leave out "isParam=\"true\"". Could you check that?
This simply means that socket sis dropped without decrementing the use count kept in "usedPooled "
Therefore, after some time usedPooled overflows the max which is by default 50 and client process cannot do remoting any more.
My recommendation is to insert
into exception handling at line 359.
Indeed, lines 362 and 385 both have the effect of eliminating a socket without decrementing the count.
Hasan, if you do the honors of posting a JIRA issue, I will see that the correction is made.
Thanks for the reply. I will test the param solution then ost my reply and create a JIRA for this issue.
I have quite busy since then. It is a shame I haven't been able to test your proposal. Sorry,
Nevertheless, thanks for the JIRA and solution.