Hi Joe
 
Ack mode is auto and the sessions are not transacted.

Thanks


-- 
Tìoraidh!

Rick Blair




> From: Joe Fernandez <[EMAIL PROTECTED]>
> Reply-To: <users@activemq.apache.org>
> Date: Sun, 12 Oct 2008 18:17:05 -0700 (PDT)
> To: <users@activemq.apache.org>
> Subject: Re: Problem with losing acks(?)
> 
> 
> When creating sessions for your subscribers, what ack mode (AUTO, CLIENT, or
> DUPS_OK) are you using and are your sessions transacted?
> 
> Joe
> Get a free ActiveMQ user guide @ http://www.ttmsolutions.com
> 
> 
> Rick Blair wrote:
>> 
>> Hi all,
>> 
>> I am using ActiveMQ version 5.1 in a pub/sub system.  The broker is
>> embedded
>> with the publishers.  The publishers publish to 2 main topics with
>> selectors.  I have many subscribers distributed on the network. The
>> subscriptions are based on the selectors.  The messages are object
>> messages.
>> 
>>   During execution one subscriber(not always the same one) seems to stop
>> sending acks.  
>> 
>> In the subscriber I still see the onMessage method call being called.
>> However on the broker, using jconsole looking at the subscription, the
>> number of messages waiting for ack = the prefetch size and the number of
>> queued messages increases.
>> 
>>   This goes on until the broker memory limit hits 100% and all message
>> flow
>> stops. 
>> 
>>  We have tried to set the policies that discard older messages, but that
>> did
>> not help.  The message discard count does increase to a point, then
>> remains
>> constant, while the enqueue count still increases.  Also at this time many
>> of the stats go negative.  This very often occurs right after startup
>> under
>> heavy load on the producers.  Thread dumps show no threads blocked, the
>> CPU
>> is not heavily loaded. GC does not seem to an issue.
>> 
>> Any suggestions?
>>  
>> -- 
>> Tìoraidh!
>> 
>> Rick
>> 
>> 
>> 
> 
> -- 
> View this message in context:
> http://www.nabble.com/Problem-with-losing-acks%28-%29-tp19934087p19947672.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> 

Reply via email to