[jira] [Updated] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Barlabanov updated AMQ-5445:
---
Description:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
was:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged (no session commit).
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 witch AMQ RAR, ActiveMQ
5.10.0 running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
Sergiy Barlabanov created AMQ-5445:
--
Summary: Message acknowledged despite of an exception thrown by a
message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 witch AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Barlabanov updated AMQ-5445:
---
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone. (was: Windows, Glassfish 3.1.2.2 witch AMQ RAR, ActiveMQ
5.10.0 running standalone.)
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219502#comment-14219502
]
Sergiy Barlabanov commented on AMQ-5445:
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
e);
connection.onClientInternalException(e);
}
}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing.
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219502#comment-14219502
]
Sergiy Barlabanov edited comment on AMQ-5445 at 11/20/14 3:43 PM:
--
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
rollbackException);
connection.onClientInternalException(rollbackException);
}
}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing.
was (Author: barlabanov):
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
e);
connection.onClientInternalException(e);
}
}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing.
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219502#comment-14219502
]
Sergiy Barlabanov edited comment on AMQ-5445 at 11/20/14 3:45 PM:
--
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
{code}
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
rollbackException);
connection.onClientInternalException(rollbackException);
}
}
{code}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing.
was (Author: barlabanov):
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
rollbackException);
connection.onClientInternalException(rollbackException);
}
}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing.
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Barlabanov updated AMQ-5445:
---
Description:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledged with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
was:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledged with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219502#comment-14219502
]
Sergiy Barlabanov edited comment on AMQ-5445 at 11/20/14 3:46 PM:
--
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
{code}
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
rollbackException);
connection.onClientInternalException(rollbackException);
}
}
{code}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing. I did not find an easy way to do this. It would
be better to rollback in ServerSessionImpl#afterDelivery - it is also mentioned
in the comment in that catch{} clause. So currently
ServerSessionImpl#afterDelivery does not know anything about whether it has to
rollback or commit. It is just committing.
was (Author: barlabanov):
And the patch would be I guess to extend the catch {} clause in
org.apache.activemq.ActiveMQSession#run and make it look something like this:
{code}
} catch (Throwable e) {
LOG.error(error dispatching message: , e);
// A problem while invoking the MessageListener does not
// in general indicate a problem with the connection to the
broker, i.e.
// it will usually be sufficient to let the afterDelivery()
method either
// commit or roll back in order to deal with the exception.
// However, we notify any registered client internal exception
listener
// of the problem.
connection.onClientInternalException(e);
if (transactionContext != null
transactionContext.isInLocalTransaction()) {
try {
rollback();
} catch (Throwable rollbackException) {
LOG.error(Error while trying to rollback the session,
rollbackException);
connection.onClientInternalException(rollbackException);
}
}
{code}
or may be there is another way to let
org.apache.activemq.ra.ServerSessionImpl#afterDelivery know that it has to
rollback instead of committing.
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledge with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be
[jira] [Updated] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Barlabanov updated AMQ-5445:
---
Description:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledged with the following message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
was:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledged with the message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledged with the following message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5445) Message acknowledged despite of an exception thrown by a message driven bean
[
https://issues.apache.org/jira/browse/AMQ-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Barlabanov updated AMQ-5445:
---
Description:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledged with the following message coming from
org.apache.activemq.ra.ServerSessionImpl:
{{Local transaction had not been commited. Commiting now.}}
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
was:
When a Glassfish server is going down, messages being currently delivered to a
MDB, are acknowledged with the following message coming from
org.apache.activemq.ra.ServerSessionImpl:
Local transaction had not been commited. Commiting now.
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an XA
transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails with
an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local or
not) the corresponding message may not be acknowledged - it must be rollbacked
(no session commit).
Message acknowledged despite of an exception thrown by a message driven bean
Key: AMQ-5445
URL: https://issues.apache.org/jira/browse/AMQ-5445
Project: ActiveMQ
Issue Type: Bug
Components: JCA Container
Affects Versions: 5.10.0
Environment: Windows, Glassfish 3.1.2.2 with AMQ RAR, ActiveMQ 5.10.0
running standalone.
Reporter: Sergiy Barlabanov
When a Glassfish server is going down, messages being currently delivered to
a MDB, are acknowledged with the following message coming from
org.apache.activemq.ra.ServerSessionImpl:
{{Local transaction had not been commited. Commiting now.}}
Having analyzed the problem, we discovered, that when Glassfish is going down
the method endpoint#beforeDelivery
(org.apache.activemq.ra.ServerSessionImpl#beforeDelivery) does not start an
XA transaction. So ActiveMQ starts a local transaction in
org.apache.activemq.ActiveMQSession#doStartTransaction. After that
ActiveMQSession#run tries to call messageListener.onMessage() and it fails
with an exception. Exception is handled in ActiveMQSession#run, but is not
propagated to org.apache.activemq.ra.ServerSessionImpl#afterDelivery. And in
org.apache.activemq.ra.ServerSessionImpl#afterDelivery there is finally {}
clause, which commits the session if there is local transaction (and there is
one - see above) despite the exception occurred before.
This last commit seems to be inappropriate. In case of a transaction (local
or not) the corresponding message may not be acknowledged - it must be
rollbacked (no session commit).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQCPP-555) AcE427
hossein mirzaeei created AMQCPP-555: --- Summary: AcE427 Key: AMQCPP-555 URL: https://issues.apache.org/jira/browse/AMQCPP-555 Project: ActiveMQ C++ Client Issue Type: Wish Affects Versions: 3.7.1 Reporter: hossein mirzaeei Assignee: Timothy Bish Priority: Critical -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5446) activemq doesn't start in java home contain space character
Herve Dumont created AMQ-5446: - Summary: activemq doesn't start in java home contain space character Key: AMQ-5446 URL: https://issues.apache.org/jira/browse/AMQ-5446 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.10.0 Environment: cygwin Reporter: Herve Dumont Priority: Minor Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACTIVEMQ6-44) Error Parsing UDP after interrupt process
clebert suconic created ACTIVEMQ6-44: Summary: Error Parsing UDP after interrupt process Key: ACTIVEMQ6-44 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-44 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: clebert suconic Assignee: clebert suconic Fix For: 6.0.0 during an interrupted send the UDP Discovery Thread could be interrupted due to an exception. The process should be more resilient to failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5446) activemq doesn't start in java home contain space character
[ https://issues.apache.org/jira/browse/AMQ-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219945#comment-14219945 ] Jesse Fugitt commented on AMQ-5446: --- Sounds like this was what I was seeing on Windows and I attached a patch to JIRA 5422: https://issues.apache.org/jira/browse/AMQ-5422 I didn't test on Linux but that patch should help for windows. Basically the variable needs quotes around it in the script. -Djava.security.auth.login.config=%ACTIVEMQ_CONF%\login.config should be -Djava.security.auth.login.config=%ACTIVEMQ_CONF%\login.config activemq doesn't start in java home contain space character --- Key: AMQ-5446 URL: https://issues.apache.org/jira/browse/AMQ-5446 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.10.0 Environment: cygwin Reporter: Herve Dumont Priority: Minor Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5446) activemq doesn't start in java home contain space character
[ https://issues.apache.org/jira/browse/AMQ-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219945#comment-14219945 ] Jesse Fugitt edited comment on AMQ-5446 at 11/20/14 8:35 PM: - Updating my comment now that I re-read and see you are referring to Java home having a space. I was having a similar problem when ActiveMQ was installed to a directory path with spaces (like Program Files). Maybe this other info could help you. Based on what I was seeing on Windows, I attached a patch to JIRA 5422: https://issues.apache.org/jira/browse/AMQ-5422 I didn't test on Linux but that patch should help for windows. Basically the variable needs quotes around it in the script. -Djava.security.auth.login.config=%ACTIVEMQ_CONF%\login.config should be -Djava.security.auth.login.config=%ACTIVEMQ_CONF%\login.config was (Author: jfugitt): Sounds like this was what I was seeing on Windows and I attached a patch to JIRA 5422: https://issues.apache.org/jira/browse/AMQ-5422 I didn't test on Linux but that patch should help for windows. Basically the variable needs quotes around it in the script. -Djava.security.auth.login.config=%ACTIVEMQ_CONF%\login.config should be -Djava.security.auth.login.config=%ACTIVEMQ_CONF%\login.config activemq doesn't start in java home contain space character --- Key: AMQ-5446 URL: https://issues.apache.org/jira/browse/AMQ-5446 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.10.0 Environment: cygwin Reporter: Herve Dumont Priority: Minor Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5446) activemq doesn't start in java home contain space character
[ https://issues.apache.org/jira/browse/AMQ-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Dumont updated AMQ-5446: -- Description: Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, like c:\Program files\Java , activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. was: Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. activemq doesn't start in java home contain space character --- Key: AMQ-5446 URL: https://issues.apache.org/jira/browse/AMQ-5446 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.10.0 Environment: cygwin Reporter: Herve Dumont Priority: Minor Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, like c:\Program files\Java , activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5446) activemq doesn't start in java home contain space character
[ https://issues.apache.org/jira/browse/AMQ-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220006#comment-14220006 ] Herve Dumont commented on AMQ-5446: --- AMQ-5422 is about activemq .bat but this issue is about activemq shell script as I'm using cygwin. $EXEC_OPTION $DOIT_PREFIX $JAVACMD $ACTIVEMQ_OPTS $ACTIVEMQ_DEBUG_OPTS \ lines in activemq script should be replaced by $EXEC_OPTION $DOIT_PREFIX \$JAVACMD\ $ACTIVEMQ_OPTS $ACTIVEMQ_DEBUG_OPTS \ double quotes around $JAVACMD are already present in activemq-admin script on the other end. activemq doesn't start in java home contain space character --- Key: AMQ-5446 URL: https://issues.apache.org/jira/browse/AMQ-5446 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.10.0 Environment: cygwin Reporter: Herve Dumont Priority: Minor Found on cygwin/Windows 7 but should be application for Linux/Unix platform too If Java is installed in a directory containing space character, like c:\Program files\Java , activemq start command doesn't start Script doesn't report any error. activemq.pid file pid of a process which doesn't exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACTIVEMQ6-44) Error Parsing UDP after interrupt process
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220019#comment-14220019 ] clebert suconic commented on ACTIVEMQ6-44: -- https://github.com/apache/activemq-6/pull/22 Error Parsing UDP after interrupt process - Key: ACTIVEMQ6-44 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-44 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: clebert suconic Assignee: clebert suconic Fix For: 6.0.0 during an interrupted send the UDP Discovery Thread could be interrupted due to an exception. The process should be more resilient to failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ACTIVEMQ6-44) Error Parsing UDP after interrupt process
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ACTIVEMQ6-44. Resolution: Fixed Error Parsing UDP after interrupt process - Key: ACTIVEMQ6-44 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-44 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: clebert suconic Assignee: clebert suconic Fix For: 6.0.0 during an interrupted send the UDP Discovery Thread could be interrupted due to an exception. The process should be more resilient to failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5440) KahaDB error at startup Looking for key N but not found in fileMap
[
https://issues.apache.org/jira/browse/AMQ-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220075#comment-14220075
]
Jesse Fugitt commented on AMQ-5440:
---
Debugged this a little more but the root cause isn't obvious even after adding
more trace debugging. Basically, the metadata that is written to disk at the
time the checkpoint cleanup was done looks correct and would not cause a
startup error because it is not referencing the files that are being cleaned
and deleted from disk. However, upon restart, a different set of metadata is
loaded from disk which is old and still references a file that was deleted
during the last checkpoint cleanup which causes the exception during
open/recover as shown in the stack trace. One workaround I tried was to force
a rebuild of the index through journal replay for any exception thrown by the
recover method (as shown below) but it doesn't feel like this is really getting
to the root of the problem.
//inside the open method:
public void open() throws IOException {
...
startCheckpoint();
//recover //instead try to catch exceptions and rebuild the index
try {
recover();
} catch (IOException ex) {
LOG.warn(Recovery failure during open. Recovering the index
through journal replay., ex);
// try to recover index
try {
pageFile.unload();
} catch (Exception ignore) {}
if (archiveCorruptedIndex) {
pageFile.archive();
} else {
pageFile.delete();
}
metadata = createMetadata();
pageFile = null;
loadPageFile();
recover();
}
KahaDB error at startup Looking for key N but not found in fileMap
Key: AMQ-5440
URL: https://issues.apache.org/jira/browse/AMQ-5440
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Priority: Critical
Attachments: KahaDB.zip, TestApp.java, kahadbtest.log
After being shutdown uncleanly, KahaDB can hit a startup error at times that
causes the broker to fail to start up and potentially causes messages to be
re-assigned that are not marked as redelivered.
The log message at startup is:
2014-11-17 11:10:36,826 | ERROR | Looking for key 275 but not found in
fileMap: {305=db-305.log number = 305 , length = 8217, 304=db-304.log number
= 304 , length = 8217, 307=db-307.log number = 307 , length = 8217,
306=db-306.log number = 306 , length = 8217, 309=db-309.log number = 309 ,
length = 8217, 308=db-308.log number = 308 , length = 8217, 311=db-311.log
number = 311 , length = 8217, 310=db-310.log number = 310 , length = 8217,
313=db-313.log number = 313 , length = 8217, 312=db-312.log number = 312 ,
length = 8217, 314=db-314.log number = 314 , length = 317, 303=db-303.log
number = 303 , length = 8433} |
org.apache.activemq.store.kahadb.disk.journal.Journal | main
and the stack trace is:
Starting TestApp...
INFO | KahaDB is version 5
ERROR | Looking for key 275 but not found in fileMap: {305=db-305.log number
= 305 , length = 8217, 304=db-304.log number = 304 , length = 8217,
307=db-307.log number = 307 , length = 8217, 306=db-306.log number = 306 ,
length = 8217, 309=db-309.log number = 309 , length = 8217, 308=db-308.log
number = 308 , length = 8217, 311=db-311.log number = 311 , length = 8217,
310=db-310.log number = 310 , length = 8217, 313=db-313.log number = 313 ,
length = 8217, 312=db-312.log number = 312 , length = 8217, 314=db-314.log
number = 314 , length = 317, 303=db-303.log number = 303 , length = 8433}
Exception in thread main java.io.IOException: Could not locate data file
KahaDB\db-275.log
at
org.apache.activemq.store.kahadb.disk.journal.Journal.getDataFile(Journal.java:353)
at
org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:600)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1014)
at
org.apache.activemq.store.kahadb.MessageDatabase.recoverProducerAudit(MessageDatabase.java:687)
at
org.apache.activemq.store.kahadb.MessageDatabase.recover(MessageDatabase.java:595)
at
org.apache.activemq.store.kahadb.MessageDatabase.open(MessageDatabase.java:400)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:418)
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:262)
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:194)
at
[jira] [Commented] (AMQ-3370) Bulk Move/Copy feature for web console
[ https://issues.apache.org/jira/browse/AMQ-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220361#comment-14220361 ] Rural Hunter commented on AMQ-3370: --- I think this is a basic requirement. Why hasn't it been implemented? Bulk Move/Copy feature for web console -- Key: AMQ-3370 URL: https://issues.apache.org/jira/browse/AMQ-3370 Project: ActiveMQ Issue Type: Wish Components: webconsole Reporter: Julien Moumné Priority: Minor Provide the ability in browse.jsp to select multiple messages and apply one of the following action : Move, Copy, Delete. This functionality would also include a Select All option which would select all messages matched by the current browse filter. Mentioned in https://issues.apache.org/jira/browse/AMQ-1326 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5447) Memory Leak after shutdown embeded broker with JDBC persistence
Shi Lei created AMQ-5447: Summary: Memory Leak after shutdown embeded broker with JDBC persistence Key: AMQ-5447 URL: https://issues.apache.org/jira/browse/AMQ-5447 Project: ActiveMQ Issue Type: Bug Components: Broker, Message Store Affects Versions: 5.10.0 Environment: Windows7, JDK7 Reporter: Shi Lei After shutdown embeded activemq broker with JDBC store, 2 'ActiveMQ JDBC PA Scheduled Task' is still alive. Because the 2 thread's Thread factory is object of JDBCPersistenceAdapter's inner class, so the object of JDBCPersistenceAdapter can be referenced from the 2 threads, JDBCPersistenceAdapter has a field point to BrokerService. So the instance of BrokerService can be referenced from the 2 threads. So the stopped brokerService cannot be GC. The root cause is that when stopping JDBCPersistenceAdapter, only cancelling cleanupTicket without shutdown clockDaemon, that's why the 2 threads are still alive. According to http://activemq.apache.org/how-do-i-restart-embedded-broker.html, it's better (more reliable) to instantiate the broker again instead of reuse old broker. So if I restart embeded broker, there will be 1 more BrokerService in memory. I think it's memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5447) Memory Leak after shutdown embeded broker with JDBC persistence
[ https://issues.apache.org/jira/browse/AMQ-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Lei updated AMQ-5447: - Description: After shutdown embeded activemq broker with JDBC store, 2 'ActiveMQ JDBC PA Scheduled Task' is still alive. Because the 2 thread's Thread factory is object of JDBCPersistenceAdapter's inner class, so the object of JDBCPersistenceAdapter can be reached from the 2 threads, JDBCPersistenceAdapter has a field point to BrokerService. So the instance of BrokerService can be reached from the 2 threads. So the stopped brokerService cannot be GC. The root cause is that when stopping JDBCPersistenceAdapter, only cancelling cleanupTicket without shutdown clockDaemon, that's why the 2 threads are still alive. According to http://activemq.apache.org/how-do-i-restart-embedded-broker.html, it's better (more reliable) to instantiate the broker again instead of reuse old broker. So if I restart embeded broker, there will be 1 more BrokerService in memory. I think it's memory leak. was: After shutdown embeded activemq broker with JDBC store, 2 'ActiveMQ JDBC PA Scheduled Task' is still alive. Because the 2 thread's Thread factory is object of JDBCPersistenceAdapter's inner class, so the object of JDBCPersistenceAdapter can be referenced from the 2 threads, JDBCPersistenceAdapter has a field point to BrokerService. So the instance of BrokerService can be referenced from the 2 threads. So the stopped brokerService cannot be GC. The root cause is that when stopping JDBCPersistenceAdapter, only cancelling cleanupTicket without shutdown clockDaemon, that's why the 2 threads are still alive. According to http://activemq.apache.org/how-do-i-restart-embedded-broker.html, it's better (more reliable) to instantiate the broker again instead of reuse old broker. So if I restart embeded broker, there will be 1 more BrokerService in memory. I think it's memory leak. Memory Leak after shutdown embeded broker with JDBC persistence --- Key: AMQ-5447 URL: https://issues.apache.org/jira/browse/AMQ-5447 Project: ActiveMQ Issue Type: Bug Components: Broker, Message Store Affects Versions: 5.10.0 Environment: Windows7, JDK7 Reporter: Shi Lei Original Estimate: 2h Remaining Estimate: 2h After shutdown embeded activemq broker with JDBC store, 2 'ActiveMQ JDBC PA Scheduled Task' is still alive. Because the 2 thread's Thread factory is object of JDBCPersistenceAdapter's inner class, so the object of JDBCPersistenceAdapter can be reached from the 2 threads, JDBCPersistenceAdapter has a field point to BrokerService. So the instance of BrokerService can be reached from the 2 threads. So the stopped brokerService cannot be GC. The root cause is that when stopping JDBCPersistenceAdapter, only cancelling cleanupTicket without shutdown clockDaemon, that's why the 2 threads are still alive. According to http://activemq.apache.org/how-do-i-restart-embedded-broker.html, it's better (more reliable) to instantiate the broker again instead of reuse old broker. So if I restart embeded broker, there will be 1 more BrokerService in memory. I think it's memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5447) Memory Leak after shutdown embeded broker with JDBC persistence
[ https://issues.apache.org/jira/browse/AMQ-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Lei updated AMQ-5447: - Attachment: JDBCPersistenceAdapter.java patch on 5.10 Memory Leak after shutdown embeded broker with JDBC persistence --- Key: AMQ-5447 URL: https://issues.apache.org/jira/browse/AMQ-5447 Project: ActiveMQ Issue Type: Bug Components: Broker, Message Store Affects Versions: 5.10.0 Environment: Windows7, JDK7 Reporter: Shi Lei Attachments: JDBCPersistenceAdapter.java Original Estimate: 2h Remaining Estimate: 2h After shutdown embeded activemq broker with JDBC store, 2 'ActiveMQ JDBC PA Scheduled Task' is still alive. Because the 2 thread's Thread factory is object of JDBCPersistenceAdapter's inner class, so the object of JDBCPersistenceAdapter can be reached from the 2 threads, JDBCPersistenceAdapter has a field point to BrokerService. So the instance of BrokerService can be reached from the 2 threads. So the stopped brokerService cannot be GC. The root cause is that when stopping JDBCPersistenceAdapter, only cancelling cleanupTicket without shutdown clockDaemon, that's why the 2 threads are still alive. According to http://activemq.apache.org/how-do-i-restart-embedded-broker.html, it's better (more reliable) to instantiate the broker again instead of reuse old broker. So if I restart embeded broker, there will be 1 more BrokerService in memory. I think it's memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
