[jira] [Created] (AMQ-5348) Network connector cause memory usage not count down

["Jiang Yunjun (JIRA)" <ji...@apache.org>]

Jiang Yunjun created AMQ-5348:
---------------------------------

             Summary: Network connector cause memory usage not count down
                 Key: AMQ-5348
                 URL: https://issues.apache.org/jira/browse/AMQ-5348
             Project: ActiveMQ
          Issue Type: Bug
    Affects Versions: 5.9.1, 5.9.0
            Reporter: Jiang Yunjun
            Priority: Critical


  We have two activeMQ servers , called A and B. A config network connector to B, and A is one way to B. We have a topic which is always sending to A, and a durable subscriber connecting to B. The problem is the "Memory percent used" in the web console do not decrease as the topic has successfully been consumed. 

     Our messages are not persistence,when we use only one activeMQ server ,this problem is not an issue. 

     I had read the source code and debuged with adding some log info.I print the stack trace info at the org.apache.activemq.command.Message.incrementReferenceCount method and org.apache.activemq.command.Message.decrementReferenceCount method. 
And I found the difference between network connectors and standalone server. 

When using network connectors there will be another incrementReferenceCount call at: 

at org.apache.activemq.command.Message.incrementReferenceCount(Message.java:659) 
        at org.apache.activemq.filter.MessageEvaluationContext.getMessage(MessageEvaluationContext.java:53) 
        at org.apache.activemq.command.NetworkBridgeFilter.matches(NetworkBridgeFilter.java:67) 
        at org.apache.activemq.network.DemandForwardingBridgeSupport.suppressMessageDispatch(DemandForwardingBridgeSupport.java:1035) 
        at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceLocalCommand(DemandForwardingBridgeSupport.java:935) 
        at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport.java:177) 
        at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116) 
        at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50) 
        at org.apache.activemq.transport.vm.VMTransport.doDispatch(VMTransport.java:138) 
        at org.apache.activemq.transport.vm.VMTransport.dispatch(VMTransport.java:127) 
        at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:104) 
        at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68) 
        at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) 
        at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1365) 
        at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:884) 
        at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:930) 
        at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133) 
        at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48) 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
        at java.lang.Thread.run(Thread.java:744) 


and I see the source code in class org.apache.activemq.network.DemandForwardingBridgeSupport : 

 private boolean suppressMessageDispatch(MessageDispatch md, DemandSubscription sub) throws Exception { 
        boolean suppress = false; 
        // for durable subs, suppression via filter leaves dangling acks so we 
        // need to check here and allow the ack irrespective 
        if (sub.getLocalInfo().isDurable()) { 
            MessageEvaluationContext messageEvalContext = new MessageEvaluationContext(); 
            messageEvalContext.setMessageReference(md.getMessage()); 
            messageEvalContext.setDestination(md.getDestination()); 
            suppress = !sub.getNetworkBridgeFilter().matches(messageEvalContext); 
        } 
        return suppress; 
    } 

this method create a MessageEvaluationContext() , and in the  "!sub.getNetworkBridgeFilter().matches(messageEvalContext);"  the MessageEvaluationContext's getMessage() method will be invoked and the incrementReferenceCount method there will be called. 
And the newly created messageEvalContext will be gc after the  suppressMessageDispatch method is invoked over. But messageEvalContext.clear method is not called so the decrementReferenceCount is not called. 

I don't know whether it is a bug or just a nice design. 

BTW,we use activeMQ 5.9 and tried 5.9.1 ,5.10.0. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)