[
https://issues.apache.org/jira/browse/AMQ-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046282#comment-16046282
]
Torsten Mielke commented on AMQ-6700:
-------------------------------------
Here are the low level details that will lead to leaking ActiveMQConnection
objects and threads:
The Arjuna transaction manager of JBoss EAP runs a periodic recovery and calls
{{ActiveMQResourceAdapter.TransactionContext.recover()}}
{code}
try {
original = setConnection(newConnection());
...
{code}
Note around the same code path would be executed when Arjuna calls {{commit()}}
or {{rollback()}} on the resource adapter.
The call to {{ActiveMQResourceAdapter.newConnection()}} is implemented as
{code}
private ActiveMQConnection newConnection() throws
JMSException {
ActiveMQConnection connection = makeConnection();
connection.start();
return connection;
}
{code}
Method {{makeConnection()}} calls into
{{ActiveMQConnectionFacotry.createActiveMQConnection()}} which contains
{code}
try {
connection = createActiveMQConnection(transport, factoryStats);
...
transport.start();
...
return connection;
} catch (JMSException e) {
// Clean up!
try {
connection.close();
} catch (Throwable ignore) {
}
throw e;
} catch (Exception e) {
// Clean up!
try {
connection.close();
} catch (Throwable ignore) {
}
throw JMSExceptionSupport.create("Could not connect to broker URL:
" + brokerURL + ". Reason: " + e, e);
}
{code}
Now if transport.start() raises an errror, this may not result in an exception
in this method. Instead the "ActiveMQ Connection Executor" thread is used to
call {{ActiveMQConnection.transportFailed()}}. So the handling of the error
happens in a different thread. Meanwhile above method
{{ActiveMQConnectionFacotry.createActiveMQConnection()}} finishes (without
exceptions) and we are back in {{ActiveMQResourceAdapter.$2.newConnection()}}
where we call {{connection.start()}} (See code sample above).
In the meantime the "ActiveMQ Connection Executor" thread has most likely
finished and marked the connection as failed
(ActiveMQConnection.transportFailed = true).
{{ActiveMQConnection.start()}} calls method
{{ActiveMQConnectioncheckClosedOrFailed()}} which checks for the value of
property {{transportFailed}}, which will be true by now and an exception will
be raised.
That exception is only caught in {{ActiveMQResourceAdapter.recover()}} which in
its {{finally}} clause calls
{code}
} finally {
closeConnection(original);
}
{code}
but original is null at this stage, so the ActiveMQConnection instance does not
get closed and the "ActiveMQ Connection Executor" thread is not shut down!
Both, the thread and the instance are leaked!
> Leak of "ActiveMQ Connection Executor" threads and ActiveMQConnection objects
> in JCA
> ------------------------------------------------------------------------------------
>
> Key: AMQ-6700
> URL: https://issues.apache.org/jira/browse/AMQ-6700
> Project: ActiveMQ
> Issue Type: Bug
> Components: JCA Container, RAR
> Affects Versions: 5.14.5
> Environment: JCA
> Reporter: Torsten Mielke
> Assignee: Torsten Mielke
> Labels: jca
>
> The ActiveMQ JCA layer may leak threads of name {{"ActiveMQ Connection
> Executor"}} and instances of {{org.apache.activemq.ActiveMQConnection}} when
> there are problems with establishing the connection.
> If the initial openwire connection cannot be established, it may run an
> "ActiveMQ Connection Executor" thread to deal with the error leading to a
> code path that does not close the connection and does not clear up the
> "ActiveMQ Connection Executor" thread.
> Low level details in further comments.
>
> This problem can be reproduced by running
> {{ActiveMQResourceAdapter.TransactionContext.recover()}} but potentially
> other code paths in the resource adapter are effected as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
