Thanks. Will try.

More detail about the client is that when we send a queue request, we do

- create a Session
- create a TemporaryQueue

I wonder if these two will be broadcasting something to the other clients
and cause the backlog. Shouldn't be, but...



rajdavies wrote:
> 
> Does this behaviour change if you use the latest snapshot ?
> 
> thanks,
> 
> Rob
> On 20 Jul 2009, at 03:51, mquestioner wrote:
> 
>>
>> Hi,
>>
>> We have a case where a consumer connected through a slow connection  
>> would
>> slow down the fast consumer. I have already
>> http://activemq.apache.org/slow-consumers.html and
>> http://activemq.apache.org/slow-consumer-handling.html However,  
>> there are
>> specific advises do not seem applicable to our scenario.
>>
>> Out set up looks like:
>> The server
>>   Constantly broadcasting non-persistent messages over a topic (a)
>>   Listen on a number of persistent and non-persistent queues to  
>> process
>> messages asynchronously (Listener) (b)
>>     Reply to the temporary queue of the request (c)
>>
>> The client
>>   Listen to the broadcast messages in background (d)
>>   Make request to the queues (e)
>>      Wait for reply (f)
>>
>> When the clients are on fast connection, everything is fine.  
>> However, once a
>> slow connecting client joins, we observe:
>>
>> 1) (e) and (f) of the fast client become extremely sluggish instantly.
>>
>> 2) Timestamp logging of (b) and (c) shows that the server still  
>> takes very
>> little time to process each request, ruling out problems such as DB
>> bottleneck. On the other hand, the messaging waiting time (time at  
>> the entry
>> of the listner - msg.getJMStimestamp()) increases by 50-100X
>>
>> 3) Either killing the slow connecting client or stop broadcasting  
>> message
>> will have things return to normal
>>
>> The strange thing is that, according to
>> http://activemq.apache.org/slow-consumers.html, ``A slow consumer is  
>> not
>> really an issue with queues.'' And that the problem occurs almost  
>> instantly
>> after the slow connection is established, it seems too short for any  
>> memory
>> usage built-up; and indeed no such problem is observed. We also try  
>> twisting
>> ActiveMQ broker and consumer settings like prefetchsize=2000,  
>> dedicated task
>> runner = true/false,  increase memoryLimit/memoryUsage,
>> optimizedDispatch=true. None seems to solve the problem.
>>
>> What would be the causes and solutions for these scenario?
>>
>> (The ActiveMQ site's suggestions of discarding old messages would  
>> create
>> stale data problems for our application.)
>>
>> Thanks a lot!
>>
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/Slow-consumers-slow-down-fast-consumer-queue-requests-tp24563120p24563120.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Slow-consumers-slow-down-fast-consumer-queue-requests-tp24563120p24572207.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to