activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <>
Subject Re: What controls message redelivery when a client acknowledgment isn’t sent?
Date Sat, 18 Apr 2015 00:35:04 GMT
On Fri, Apr 17, 2015 at 4:38 PM, Tim Bain <> wrote:

> Yeah, the whole paradigm of CLIENT_ACKNOWLEDGE is "I know what I'm doing,
> don't worry about me, I'll tell you when we're good to go."  As long as the
> client is alive and still connected, it's called the ball and the broker
> won't second-guess it.

Ah.. ok.  Yeah.  That’s what I thought.  So really the only way to test
this would be to somehow kill the connection but realistically that mean
stopping the thread or killing a forked JVM.

which is somewhat hard.

> With that being said, I'd assume that either a graceful or an ungraceful
> disconnect would cause the broker to attempt to redeliver any messages that
> hadn't been acked; if that's not happening, then that would be a bug as I
> understand it.  But if your process is still alive and connected, then
> there's no automatic disconnect that I know of.
Just closing it doesn’t work.

> You could, however, set up a AbortSlowAckConsumerStrategy to kick off your
> consumer if it takes too long processing the message, which might give you
> something similar.  Be careful though; my observations using
> AbortSlowConsumerStrategy were that the aborted client would continue
> processing the message even after being aborted, so if
> AbortSlowAckConsumerStrategy behaves the same way (and when I read its code
> a while back I didn't see a reason it would be different) you open yourself
> up to processing the message twice if you use this approach.

I didn’t understand this when I wrote the code initially and thought I
understood the semantics. I really should have tested the “fork the JVM”
strategy to see what happens.

My idea was that a task processing a message should really be given an
upper ceiling of time (say 1-2 minutes) before someone else takes it over.

And yes.. that JVM could continue to process the task so that needs to be
accounted for.

I wish there was a reliable way to kill -9 a thread in Java …


Location: *San Francisco, CA*
… or check out my Google+ profile

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message