5.4.2 is really old now. A huge number of bugs have been fixed since. I would highly encourage you to upgrade to the latest version in the mid term time frame.
Torsten On Aug 21, 2012, at 3:36 PM, Tlholoe, Peter wrote: > Hi Torsten, > We are using ActiveMQ 5.4.2 > Thank you for your help, I will try that and advise of the results. > > -----Original Message----- > From: Torsten Mielke [mailto:tors...@fusesource.com] > Sent: 21 August 2012 03:25 PM > To: users@activemq.apache.org > Subject: Re: ActiveMQ hangs > > What version of ActiveMQ are you using? > Even with producer flow control disabled, the broker will still suspend > producers when it reaches any of the configured systemUsage limits. If you > don't specify any systemUsage in your brokers configuration, a default and > hard coded systemUsage applies. So producers can still be blocked. > Its perhaps better to explicitly set the systemUsage to your requirements > than rely on the defaults. > > Also, when you reach 70% of the configured queue destination memory limit, > the cursor will not store any more new msgs in memory but reload them from > the persistence adapter when its time to dispatch them. Persistent queue > messages get written to kahadb right when being received by the broker. > > Regards, > Torsten Mielke > > > > On Aug 21, 2012, at 2:30 PM, Tlholoe, Peter wrote: > >> 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. > > Torsten Mielke > tors...@fusesource.com > tmie...@blogspot.com > > > > 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. Torsten Mielke tors...@fusesource.com tmie...@blogspot.com
