Yes I've seen this before - its a bug in the dispatch logic. It was
fixed in 4.1.0.

On 12/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hello,

I'm seeing a strange issue with ActiveMQ 4.0.2. We have a single process
that generates messages and sends them to a queue. There are several
hundred client processes that consume messages from this queue. I have set
the queue prefetch policy of the client connections to 1,
useRetroactiveConsumer = true, maxInactivityDuration = 0. I'm using a
non-transacted auto-acknowledge session with the MessageConsumer.

Every now and then we get what appears to be a "lost" message. The clients
are unable to pull any more messages off the queue, but JConsole/JMX is
reporting that there is 1 message still available. Using the browseAsTable
operation I'm able to inspect the message, but nothing seems out of the
ordinary.

Has anyone seen a situation like this before? Any suggestions of what I
could do to prevent this from happening?

Thanks in advance,

Tony


-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.




--

James
-------
http://radio.weblogs.com/0112098/

Reply via email to