Messages getting "stuck" in network of brokers configuration, Kaha.

[eta <er...@ultracode.com>]

As I posted earlier, I have a two-broker network-of-brokers configuration. 
Both brokers are configured for Kaha.  I just tried a test where I dumped
10K small persistent messages in quick succession onto a queue.  The
consumers are just reading and throwing away the messages.  All clients are
using Jencks.  

The 10K messages seems to have done some kind of harm to the brokers.  After
the 1st batch of messages, using JManage I looked at the various counters on
one of the brokers and the QueueSize counter was unchanging at -3.  After
running the producer again (another 10k messages) the QueueSize went
positive, but it took a restart of all clients to get message reception
going again - all consumers had stopped prior to this.

I decided to start restart both brokers & all clients.  After doing so, I'm
now looking at my QueueSize in broker #1 and it's showing -1000 messages!

I haven't done anything particularly strange here, or at least I don't think
so anyway.

Is Kaha stable in 5.0?  Should I use JDBC instead?  What about the stability
of broker networks?

Eric
-- 
View this message in context: http://www.nabble.com/Messages-getting-%22stuck%22-in-network-of-brokers-configuration%2C-Kaha.-tf4179659s2354.html#a11885457
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Messages getting "stuck" in network of brokers configuration, Kaha.

[Mario Siegenthaler <ms...@inventsoft.ch>]

Yes, this is very annoying in some situations where you depend onto
this numbers. How hard / expensive (performance wise) would it be to
add an configuration flag so the numbers are actually fetched from the
message store instead of 'just' being the difference of (messages
sent)-(messages consumed)?
I think with a JDBC based persistence (no journal) this should be
doable with minimal costs. Journals and Kaha stores could darken the
picture, but I've no insight there.

We'll need to do some more monitoring of our queue in production to
ensure that all the messages (in our case business events such as "Mr.
X is now married to Ms. Y") are dispatched to and consumed by the
various systems connected to our ActiveMQ-Message Bus. So until we're
given an option to let activemq show 'effective' queue length the
monitoring is kinda tricky. I don't really want to explain to the
customer how it comes that the 'marriage-queue' has -20 messages in
it.. sounds like that stupid joke where 5 people have to board the bus
in order for the bus to become empty.

Mario

On 8/7/07, Tom Samplonius <to...@samplonius.org> wrote:
>
> ----- "eta" <er...@ultracode.com> wrote:
> ...
> > I decided to start restart both brokers & all clients.  After doing
> > so, I'm
> > now looking at my QueueSize in broker #1 and it's showing -1000
> > messages!
> ...
>
>   This sounds like a  known bug in ActiveMQ:  ActiveMQ is unable to determine the number of messages in the persistence store upon startup, so all counters start at zero.  If you had a 1000 messages in the store upon startup, and then consumed them, it is "normal" for ActiveMQ to say the queue now has -1000 messages in it.
>
>
>
> Tom
>

Re: Messages getting "stuck" in network of brokers configuration, Kaha.

[Tom Samplonius <to...@samplonius.org>]

----- "eta" <er...@ultracode.com> wrote:
...
> I decided to start restart both brokers & all clients.  After doing
> so, I'm
> now looking at my QueueSize in broker #1 and it's showing -1000
> messages!
...

  This sounds like a  known bug in ActiveMQ:  ActiveMQ is unable to determine the number of messages in the persistence store upon startup, so all counters start at zero.  If you had a 1000 messages in the store upon startup, and then consumed them, it is "normal" for ActiveMQ to say the queue now has -1000 messages in it.



Tom