Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com
 designates 64.233.170.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=QElpLcPk1g/ZUn1+UiQe99Zxg0e0ISxlFudqm7rLSR5PoXWLa0KvKSDs+ON8xwYvaZ
         E08owboA8IYdBMjldlmTCFu4uBXMHW2KYoQ8uSWkY3hZI0frYcVodAm9dum6W7s5njId
         41ZOCkYMNrbAtKSdJtdhNw67SbLoPa9WAJ2XI=
Message-ID: <3a73c17c0811140302h5a7fe098sccbca0a33a788da4@mail.gmail.com>
Date: Fri, 14 Nov 2008 11:02:27 +0000
From: "Gary Tully" <gary.tully@gmail.com>
To: users@activemq.apache.org
Subject: Re: AMQ-5.2.0 RC3: JMS Exception Could not correlate acknowledgment
 with dispatched message
In-Reply-To: <20494692.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20475017.post@talk.nabble.com>
	 <3a73c17c0811130148y77344503h99713c3e95d604c4@mail.gmail.com>
	 <20480533.post@talk.nabble.com>
	 <3a73c17c0811130544h10f9072bn95fc60844ee7badd@mail.gmail.com>
	 <20494692.post@talk.nabble.com>

I think you are experiencing automatic producer flow control in
response to the memory utilisation limits, see:
http://activemq.apache.org/what-happens-with-a-fast-producer-and-slow-consumer.html

The details of how to disable are at:
http://activemq.apache.org/producer-flow-control.html

Just fyi, there is a bunch of good usage information hidden in:
http://activemq.apache.org/faq.html

On restart, the slowness of recovery, this is a known issue that is
being addresses for 6.0
There is a cleanup task that works with the check pointing that can
reduce the amount of work outstanding on a restart, they run every 30
seconds or so but they are only relevant when there is consumption of
messages. with a large backlog of unconsumed messages, the active data
file list grows and the required collection of indexes that need to be
rebuilt on restart (recovery) gets large.

There are a bunch of related configuration options (data and index
file size etc)  on the Kaha store that may help some here, but the
underlying problem will not be addressed till 6.0.


2008/11/14 bonnyr <bonnyr@optusnet.com.au>:
>
> Gary,
>
> Thanks for the pointers. I'll try those. In the meantime I'm having other
> issues...
> I've cleared up the data directory in the broker area (we're using kaha for
> persistence)
> and restarted the test. I am not able to create the error again !?
> However, I've noticed another, more depressing problem :) - as long as there
> are consumers
> and producers, and the consumers keep up, I get a sustained rate that is
> reasonably stable. So far so
> good. When the consumer dies and the queue builds up, the rate gradually
> drops until (at around 1M msgs in the queue)
> it stops almost completly and will allow around 3 m/s. Connecting the
> consumer at this point does not
> help completely. In fact, the consumer is not able to consume at the maximum
> rate I've observed
> on the test rig (~1200 m/s) but rather at ~250 m/s and at that point the
> producer has recovered its
> rate to ~100 m/s. Why is that?
>
> Also, I've shut down the broker and restarted it (there were ~800K messages
> in the queue plus whatever
> other operations related to acks/deletions stored in the roll forward files)
> and it has taken so far 1h 20m
> to go through about 80% of the data files (in the journal directory) but
> what's more troubling is that
> the operation gets slower and slower, almost exponentially. Again, any idea
> as to why ?
>
> Cheers,
>
> Bonny
>
> Gary Tully wrote:
>>
>>> This test is the first time we're seeing this message - our applications
>>> are
>>> in production environments
>>> and this is not being exhibited at all, so I think our batch glue layer
>>> is
>>> not the source of the problem.
>>>
>> Ok, I am not thinking it is the source of the problem but it may be
>> the key to reproducing the problem in a test case.
>>
>>> Also, the code I'm using in the test uses other glue classes which are
>>> part
>>> of our framework and cannot
>>> be easily separated to form a stand alone test case. Could you perhaps
>>> point
>>> me to a test case that
>>> perhaps resembles my setup and I'll be happy to modify it to test what
>>> I'm
>>> trying to achieve?
>>>
>> Great. Possibly look at
>> http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/usecases/CompositePublishTest.java
>> The support class that it extends could provide some useful
>> scaffolding. Ie: this starts an embedded broker with consumers and
>> produces and validate that the produced messages were consumed.
>> Another example of the same sort of thing, creating consumers and
>> firing off loads of messages, asserting behavior is:
>> https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/JmsQueueSendReceiveUsingTwoSessionsTest.java
>>
>> Hope this helps get you started.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/AMQ-5.2.0-RC3%3A-JMS-Exception-Could-not-correlate-acknowledgment-with-dispatched-message-tp20475017p20494692.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>