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

The non-HA use-case is unaffected.


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




> [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.
> The non-HA use-case is unaffected.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to