activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From EJLeVin1 <>
Subject Re: 'Hopefully' Configuration Issue
Date Sat, 05 Jan 2008 00:19:26 GMT

We have been using 5.0 -- but today I tried seeing if the 5.1 SNAPSHOT would
be the fix, but that didn't make any difference.  One thing we were able to
solve -- we got the producer to continue sending messages even if one of the
consuming applications was "paused".  The way we did that was through using
a SimpleDispatchPolicy; HOWEVER, this caused an out-of-memory issue
eventually because it seems that although the messages are getting sent to
the other consumers that are not paused, they are seemingly also getting
queued for the paused consumer.  I am still not quite sure why this would be
(as we are setting the pendingMessageLimitStrategy to 1?  Any thoughts?

Thanks for taking the time to help!

Hiram Chirino wrote:
> What version you running with?
> On Jan 4, 2008 1:22 AM, EJLeVin1 <> wrote:
>> Hi,
>>      First off I want to say I am sorry right up front if this is a very
>> basic question, but I as well as others have been searching for a
>> solution
>> to this to no avail.  We have run into the following situation in testing
>> one of our new developments:
>> -Non-persistent TOPIC
>> -Very fast STOMP producer (>3000 msgs / sec)
>> -Multiple STOMP consumers
>> The problem we are running into is that this whole setup has been working
>> excellent up to this point; however, we discovered a major issue with
>> Slow
>> Consumers being handled.  I know that there are many questions/postings
>> regarding handling slow consumers, but yet we still are running into this
>> issue, and I am beginning to wonder if it is currently how AMQ is just
>> functionally built.  Essentially what happens is if one of these
>> consumers
>> is slow (we throttled the receive through TCPMon) or a breakpoint in hit
>> on
>> the consuming application, the producer will continue to send for a time,
>> but eventually (and quickly) goes into a wait for the send-queue of the
>> slow
>> consumer to have more space and no messages are sent to any of the
>> clients.
>> If the slow consumer disconnects or the breakpoint is done being
>> debugged,
>> everything goes back to normal, but not until that point.  Below is the
>> config file section I tried to put into place given the other forum
>> postings
>> / AMQ articles I read; however, the same result occurred.
>> What I really just want to have happen is messages get delivered to the
>> consumers on my topic as they come in, if a consumer is slow to take
>> messages and multiple messages come in while the slow delivery is
>> occurring,
>> the subsequent messages get delivered to the other consumers and then
>> just
>> thrown away.  I need to find a way to configure things where even if
>> consumers on my topic are not able to keep up, they will get messages as
>> fast as they can consume them, but they will not interfere with other
>> consumers getting the produced messages as well.  We have also tried
>> different subscription params such as:
>> activemq.dispatchAsync
>> activemq.maximumPendingMessageLimit
>> By the way, when I am sending the messages to AMQ, I am setting the
>> message
>> to non-persistent, but that also had no effect.
>> <policyEntry topic="MyTopic.>">
>>             <subscriptionRecoveryPolicy>
>>                 <noSubscriptionRecoveryPolicy/>
>>             </subscriptionRecoveryPolicy>
>>             <!-- lets force old messages to be discarded for slow
>> consumers
>> -->
>>             <pendingMessageLimitStrategy>
>>               <constantPendingMessageLimitStrategy limit="1"/>
>>             </pendingMessageLimitStrategy>
>>           </policyEntry>
>>         </policyEntries>
>> Thanks in advance for your help, I really appreciate it.
>> -Eric
>> --
>> View this message in context:
>> Sent from the ActiveMQ - User mailing list archive at
> -- 
> Regards,
> Hiram
> Blog:
> Open Source SOA

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message