activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Idzerda, Edan" <>
Subject RE: Not able to load-balance messages in a cluster using PrefetchPolicy
Date Wed, 08 Jun 2011 21:49:59 GMT
Have you tried prefetch=0 ?  I was doing some similar testing a while ago and as I recall,
prefetch=0 was the setting that behaved best for my round-robin consumer setup.

From: Joe Smith []
Sent: Wednesday, June 08, 2011 5:32 PM
Subject: Not able to load-balance messages in a cluster using PrefetchPolicy

We are using 5.4.2 running on Linux w/Java 1.6.   The cluster has 3 primary brokers and corresponding
slaves (residing on separate hosts).  We have 3 msg consumer processes  (using Springframework
w/3 concurrent threads each), connected to each broker.  Occasionally a consumer process gets
a message that has long running time due to interaction with another external system.  So
a msg could take up to 20 min to process (waiting for the other system to complete their task).
To better load balance the msgs - to prevent msgs from being stuck behind an earlier/long-running
msg, we use the prefetchPolicy.queuePrefetch=1 configuration on the ConnectionFactory.
The prefetch works - where newer msgs get distributed to other consumer threads that are free
to work in a single consumer process.  It looks like the msgs are dispatched to the 3 consumer
processes (instead of 9 consumer threads) in a round-robin fashion in the cluster.  Since
we have 3 independent consumer processes (spring/jvm), we have seen multiple msgs get dispatched
to one consumer process and waiting, while the other 2 consumer processes connected to the
other 2 brokers are idle.
Is there a correct configuration that will distribute the msgs from one broker to another
without being stuck behind a long-running consumer thread?  We can work around the issue by
increasing the number of consumer threads within each consumer process, but thought there
could be a better, more efficient solution.
We have used the following config params:
- ConnectionFactory
-       prefetchPolicy
-       dispatchAsync = false
-       useAsyncSend = false
-       alwaysSessionAsync = false
- springframework DefaultMessageListenerContainer
-       receiveTimeout = 0
- broker config xml
-       conduitSubscriptions="false"
-       we added ?jms.prefetchPolicy.all=1 to the NetworkConnector's uri attribute, we also
tried with just .queuePrefetch instead of .all.
-       we've tried different strict ordering dispatch policy - made no difference
Things we've noticed.
-       In springframework we can set the value for prefetchPolicy to either 1 or 0, but the
behavior seems to be the same.  However, we could not use value 0 when we use our pure Java
client as MessageListener.
-       Msgs are dispatched to the 3 brokers in a more or less round-robin fashion.  We have
notice occasionally that each consumer process still gets a batch of msgs.  Once it gets a
batch, it does not release any queued msgs to other brokers/consumers that are free.
There are many configuration parameters.  We may have missed some critical ones.
Thanks for your help.
Attached is the springframework config.  It's one file but I duplicated the beans for ConnectionFactory,
listener, containers, etc to simulate the 3 independent processes.  The number of thread are
all set to one for testing purposes.
The activemq.xml is pretty much the default.

***Note:The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have
received this communication in error, please notify the Sender
immediately by replying to the message and deleting it from your
computer.  Thank you.  Premier Inc.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message