activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jjiag22222 <jiangyun...@foxmail.com>
Subject Network connector cause memory usage not count down
Date Fri, 05 Sep 2014 08:29:55 GMT
      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.






--
View this message in context: http://activemq.2283324.n4.nabble.com/Network-connector-cause-memory-usage-not-count-down-tp4685296.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Mime
View raw message