[ 
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 
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.



  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 leak 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 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to