Did changing jms.prefetchPolicy.queuePrefetch to other values change the number of messages stuck behind the long-running message, just not bring it to zero? Or did it have no effect (i.e. still 62 messages stuck)?
Prefetch is the key here; any messages dispatched to the consumer that gets the long-running message will be processed by that consumer (even if others are idle and could process them) until after the long-running message is processed. If that's not acceptable, you want to set your clients' prefetch buffer size to 0, so they will only get the next message from the broker when they finish processing the current one. The downside to this configuration is that the consumer then has to wait while the current message's ack traverses the network to the broker and then while the next message traverses the network back to the consumer. For fast networks, that's probably not a big deal; for high-latency ones, that could be a deal-breaker. So as usual, you'll have to evaluate your performance requirements and configure accordingly. On May 14, 2015 12:06 PM, "Elmo" <elmo2...@email.de> wrote: > Hello, > > I've got a MessageDrivenBean, running in Glassfish 3.1.2, listening to an > ActiveMQ 5.9.0 Queue. When a Message is processed and needing a long time, > other messages wait for processing. > > Test scenario: Sending a big message (needing approx. 30 minutes to > process) > and 250 small messages while the first is still in progress. Then 62 of the > small messages wait for the big one before they get processed. > > The MessageDrivenBean has a bean-pool size of 4, in this test I did not use > a prefetch limit. Additional tests with various settings (e.g. > ?jms.prefetchPolicy.queuePrefetch=20 or ...=2, threadpool max queue size 2) > did not solve the problem, there are always small messages waiting for the > big one. > > My question is: does anybody know a way how to configure the MDB, ActiveMQ > and/or glassfish to avoid this problem? Or is this a typical scenario for > polling, e.g. by a TimerBean? I know, alternatively I could work with two > queues and two MDB (one for big and one for smaller messages), but this > would mean that some of my other JMS communication parties would need to be > changed. > > Thank you in advance and best regards, Marc > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Glassfish-3-1-2-ActiveMQ-5-9-0-MDB-Long-lasting-Message-blocks-other-Messages-tp4696328.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
