Hi,
I am currently monitoring all the queues/ topics at the moment. In the interim 
I did disable producer-flow-control, and increasing the memoryLimit=1024Mb, but 
I didn't activate systemUsage, and I read that the memory limit configuration 
is dependent on the systemUsage configuration. 
My idea of this is that in the event of a slow consumer, all the message that 
are not yet consumed can be offlined to a file system, so as not to exhaust 
broker resources and avoid profucer flow control kicking in. 

        <destinationPolicy>
            <policyMap>
              <policyEntries>
                <policyEntry topic=">" producerFlowControl="false" 
memoryLimit="1024mb">
                  <pendingSubscriberPolicy>
                    <vmCursor />
                  </pendingSubscriberPolicy>
                </policyEntry>
                <policyEntry queue=">" producerFlowControl="false" 
memoryLimit="1024mb">
                  <!-- Use VM cursor for better latency
                       For more information, see:
                       
                       http://activemq.apache.org/message-cursors.html
                       
                  <pendingQueuePolicy>
                    <vmQueueCursor/>
                  </pendingQueuePolicy>
                  -->
                </policyEntry>
              </policyEntries>
            </policyMap>
        </destinationPolicy>


System Usage
      <!--  <systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="20 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="1 gb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="100 mb"/>
                </tempUsage>
            </systemUsage>
        </systemUsage>          -->


-----Original Message-----
From: Torsten Mielke [mailto:tors...@fusesource.com] 
Sent: 21 August 2012 10:46 AM
To: users@activemq.apache.org
Subject: Re: ActiveMQ hangs

Hello,

In your Camel route you seem to route message from various destinations on the 
broker to other destinations on the same broker.
Is it possible that the destinations you route message to are getting filled up 
(not all, but some of them). 
If that happens, producer flow control might kick in, causing the Camel route 
producers to be put on hold until more messages get consumed. 
If the Camel route producer is stalled, the entire Camel route is stalled.
http://activemq.apache.org/producer-flow-control.html

I suggest you monitor all queues and topics on the broker using either the web 
console or JMX. 
Also, a thread dump of the broker and the Camel route (in case it runs external 
to the broker) could help you to find out in what state the broker and your 
Camel route are. 



Torsten Mielke
tors...@fusesource.com
tmie...@blogspot.com


On Aug 21, 2012, at 9:32 AM, Tlholoe, Peter wrote:

> We currently have a problem in our production environment. We have one 
> general purpose topic where all messages are published to, and A Camel  
> subscribed to that general purpose topic, apply rules to route the messages 
> to different topics. That consumer constantly has higher 
> MessageCountAwaitingAcknowledge and higer DispachedQueueSize (around 2000). 
> Our PROD is a high message traffic message environment.
>  
> Any pointers on what might be causing this. Please see attached our 
> activemq.xml and camel.xml.
> To read FirstRand Bank's Disclaimer for this email click on the following 
> address or copy into your Internet browser: 
> https://www.fnb.co.za/disclaimer.html 
> 
> If you are unable to access the Disclaimer, send a blank e-mail to 
> firstrandbankdisclai...@fnb.co.za and we will send you a copy of the 
> Disclaimer.
> <activemq.xml><camel.xml>




To read FirstRand Bank's Disclaimer for this email click on the following 
address or copy into your Internet browser: 
https://www.fnb.co.za/disclaimer.html 

If you are unable to access the Disclaimer, send a blank e-mail to
firstrandbankdisclai...@fnb.co.za and we will send you a copy of the Disclaimer.

Reply via email to