Gary, 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. 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?
Also, regarding the performance - I know we had obtained in similar setups a much higher rate in the past so I'm not sure what the issue there is, altough it currently is secondary to this exception. Cheers, Bonny Gary Tully wrote: > > I think the interesting bit is the batch logic in the consumers. > Could you raise a jira and post your test case? > If you could coerce the broker, producers and consumers into a single > java application so that it can be converted into a junit test case it > would be great. > > The key to pining this down is the reproducible test case. 1000 m/s > and/or running on a single host should not be a problem. > > 2008/11/13 bonnyr <[EMAIL PROTECTED]>: >> >> All, >> >> We've been using AMQ for a while now, and wanted to test the upcoming >> release to see if it resolved >> a problem we're having with the current version we're using (5.1.0), so >> I've >> setup a test to try >> and create the problem in my test environment. >> >> My setup is: >> ----------- >> 1 producer, producing messages to a queue at a high rate (~1000 m/s). The >> message payload is a >> simple POJO we use for our project. >> >> 2 consumers connected to the same queue, one as primary and the other as >> secondary (arbitrary >> designation, but done such that the primary will be collecting the >> messages if it's connected). >> each consumer consumes messages in a batch (some glue layer in our app >> does this), and simply >> acknowledges the last message in the batch. >> >> 1 broker hosting the queue. >> >> All 4 executables are running on the same host. All AMQ clients are >> written >> in Java. Test is running on WinXP SP3 >> >> >> After executing for a little while, I am getting the exception in the >> title. >> Once it occures, the simple >> test clients are simply disconnected and hang, not able to receive any >> more. >> >> Can someone suggest a way to try and pin this down? Is this a performance >> problem? Is it related to >> the fact that it's running on the same host? >> >> Any help will be appreciated. >> >> Cheers, >> >> Bonny. >> >> PS. the production/consumption rate seems to get stuck at around 1000 m/s >> which is quite a bit lower >> than when we originally tested (with 4.1.1) - any idea on what I can do >> to >> improve this? >> >> >> -- >> View this message in context: >> http://www.nabble.com/AMQ-5.2.0-RC3%3A-JMS-Exception-Could-not-correlate-acknowledgment-with-dispatched-message-tp20475017p20475017.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/AMQ-5.2.0-RC3%3A-JMS-Exception-Could-not-correlate-acknowledgment-with-dispatched-message-tp20475017p20480533.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
