activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AMQ-4248) FilePendingMessageCursor can retain memory after flush to disk till next reset via internal iterator
Date Fri, 11 Jan 2013 20:44:12 GMT

    [ https://issues.apache.org/jira/browse/AMQ-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551501#comment-13551501
] 

Timothy Bish edited comment on AMQ-4248 at 1/11/13 8:42 PM:
------------------------------------------------------------

The problem comes from a second attempt to dispatch a the message when the dispatchAsync mode
is on and the TransportConnection calls the transmitCallback:

{noformat}
	at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.reset(FilePendingMessageCursor.java:137)
	at org.apache.activemq.broker.region.cursors.StoreDurableSubscriberCursor.reset(StoreDurableSubscriberCursor.java:287)
	at org.apache.activemq.broker.region.PrefetchSubscription.dispatchPending(PrefetchSubscription.java:627)
	at org.apache.activemq.broker.region.DurableTopicSubscription.dispatchPending(DurableTopicSubscription.java:265)
	at org.apache.activemq.broker.region.PrefetchSubscription.onDispatch(PrefetchSubscription.java:731)
	at org.apache.activemq.broker.region.PrefetchSubscription$3.run(PrefetchSubscription.java:705)
	at org.apache.activemq.broker.TransportConnection.dispatchAsync(TransportConnection.java:816)
	at org.apache.activemq.broker.region.PrefetchSubscription.dispatch(PrefetchSubscription.java:708)
	at org.apache.activemq.broker.region.PrefetchSubscription.dispatchPending(PrefetchSubscription.java:651)
	at org.apache.activemq.broker.region.DurableTopicSubscription.dispatchPending(DurableTopicSubscription.java:265)
	at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:161)
	at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:259)
	at org.apache.activemq.broker.region.policy.SimpleDispatchPolicy.dispatch(SimpleDispatchPolicy.java:48)
	at org.apache.activemq.broker.region.Topic.dispatch(Topic.java:688)
	at org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:499)
	at org.apache.activemq.broker.region.Topic.send(Topic.java:435)
	at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:408)
	at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:392)
	at org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:282)
	at org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)
	at org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:317)
	at org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:135)
	at org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:448)
	at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:749)
	at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
	at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:150)
	at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
	at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
	at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:278)
	at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
	at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
	at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
	at java.lang.Thread.run(Thread.java:722)

{noformat}

This happens when the transport is stopping but a message was queued for dispatch.  Although
I think this would happen from the other calls to the transmitcallback as they all invoke
another dispatch cycle from PrefetchSubscription.onDispatch
                
      was (Author: tabish121):
    The problem comes from a second attempt to dispatch a the message when the dispatchAsync
mode is on and the TransportConnection calls the transmitCallback:

{noformat}
	at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.reset(FilePendingMessageCursor.java:137)
	at org.apache.activemq.broker.region.cursors.StoreDurableSubscriberCursor.reset(StoreDurableSubscriberCursor.java:287)
	at org.apache.activemq.broker.region.PrefetchSubscription.dispatchPending(PrefetchSubscription.java:627)
	at org.apache.activemq.broker.region.DurableTopicSubscription.dispatchPending(DurableTopicSubscription.java:265)
	at org.apache.activemq.broker.region.PrefetchSubscription.onDispatch(PrefetchSubscription.java:731)
	at org.apache.activemq.broker.region.PrefetchSubscription$3.run(PrefetchSubscription.java:705)
	at org.apache.activemq.broker.TransportConnection.dispatchAsync(TransportConnection.java:816)
	at org.apache.activemq.broker.region.PrefetchSubscription.dispatch(PrefetchSubscription.java:708)
	at org.apache.activemq.broker.region.PrefetchSubscription.dispatchPending(PrefetchSubscription.java:651)
	at org.apache.activemq.broker.region.DurableTopicSubscription.dispatchPending(DurableTopicSubscription.java:265)
	at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:161)
	at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:259)
	at org.apache.activemq.broker.region.policy.SimpleDispatchPolicy.dispatch(SimpleDispatchPolicy.java:48)
	at org.apache.activemq.broker.region.Topic.dispatch(Topic.java:688)
	at org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:499)
	at org.apache.activemq.broker.region.Topic.send(Topic.java:435)
	at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:408)
	at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:392)
	at org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:282)
	at org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)
	at org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:317)
	at org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:135)
	at org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:448)
	at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:749)
	at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
	at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:150)
	at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
	at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
	at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:278)
	at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
	at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
	at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
	at java.lang.Thread.run(Thread.java:722)

{noformat}

                  
> FilePendingMessageCursor can retain memory after flush to disk till next reset via internal
iterator
> ----------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-4248
>                 URL: https://issues.apache.org/jira/browse/AMQ-4248
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.6.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>              Labels: cursor, memory, oom
>             Fix For: 5.8.0
>
>
> the contract for cursor iteration is to call {code}reset,next...,release{code} 
> If the cursor is flushed on add, the memory list is cleared but the iterator is still
referencing the list, which causes memory bloat. It will be released on the next call to reset
(which may take some time depending on consumer activity), but it should be gone after the
previous call to release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message