[
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7977:
-----------------------------
Description:
During the work of QPID-7832, it was noticed that there is a potential for the
direct memory used for uncommitted messages to be leaked when a node loses the
mastership.
The test that exposed the direct leak is:
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
I think the problem is this. When mastership is lost, the underlying database
operations that occur after fail. One possible place this can occur is the is
the rolling back open transactions. The rollback causes the store to try and
remove the messages {{
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
The underlying database operation fails on line
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
This prevents the direct memory associated with the messages from being
released. One possible fix is a simple try/finally. There might be other
places that need similar attention.
The operation of the group is unaffected, and there is no message loss. The
JVM should eventually release the direct memory itself.
was:
During the work of QPID-7832, it was noticed that there is a potential for the
direct memory used for uncommitted messages to be leaked when a node loses the
mastership.
The test that exposed the direct leak is:
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
I think the problem is this. When mastership is lost, the underlying database
operation fail. For instance, the virtualhost that was master is rolling back
open transactions. This causes the messages that were committed to the store
to be removed
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
The underlying database operation fails
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085),
this prevents the direct memory associated with the messages from being
released. One possible fix is a simple try/finally. There might be other
places that need similar attention.
The operation of the group is unaffected, and there is no message loss. The
JVM should eventually release the direct memory itself.
> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> ----------------------------------------------------------------------
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
> Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for
> the direct memory used for uncommitted messages to be leaked when a node
> loses the mastership.
> The test that exposed the direct leak is:
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this. When mastership is lost, the underlying
> database operations that occur after fail. One possible place this can occur
> is the is the rolling back open transactions. The rollback causes the store
> to try and remove the messages {{
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
> The underlying database operation fails on line
> {{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
> This prevents the direct memory associated with the messages from being
> released. One possible fix is a simple try/finally. There might be other
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss. The
> JVM should eventually release the direct memory itself.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
