[
http://jira.jboss.com/jira/browse/JBREM-911?page=comments#action_12400787 ]
Ron Sigal commented on JBREM-911:
---------------------------------
The source of the problem is the change in
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport() introduced for
JBREM-786 "stale sockets can be gotten from pool even with current rety logic".
In particular, MicroSocketClientInvoker.getConnection() is configured to try to get an
existing connection from the connection pool unless:
* it is currently on its last try, according to the value of numberOfCallRetries, or
* the maximum size of the connection pool is one.
The problem is that if numberOfCallRetries is set to one, getConnection() will *always*
try to create a new connection and will never use the connection pool.
Added a test so that getConnection() will also try to get an existing connection if
numberOfCallRetries == 1.
Unit test:
org.jboss.test.remoting.transport.socket.connectionpool.ConnectionPoolSingleRetryTestCase.
Waiting for hudson results.
Check out thread leak
---------------------
Key: JBREM-911
URL:
http://jira.jboss.com/jira/browse/JBREM-911
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Priority: Blocker
Fix For: 2.4.0.CR1 (Pinto)
A JBossMessaging user has reported
"Using 2.4.0.Beta1 (Pinto) -- we seem to get 1 new thread for every message received
on the consumer - until it eventually (at about 4000 messages) throws an error (either
"OutOfMemoryError: GC overhead limit exceeded" or "OutOfMemoryError: unable
to create new native thread")."
--
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