activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: What controls message redelivery when a client acknowledgment isn’t sent?
Date Thu, 23 Apr 2015 12:47:55 GMT
On Apr 17, 2015 6:36 PM, "Kevin Burton" <> wrote:
> 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
> > don't worry about me, I'll tell you when we're good to go."  As long as
> > 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.

Just for the purpose of this test, can you switch to using a standalone
broker to make it easier to kill your consumer?

> > 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
> > hadn't been acked; if that's not happening, then that would be a bug as
> > 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.

Just closing what?  Your comments elsewhere in your response make it sound
like you haven't been able to close the consumer/connection, so what do you
mean here?

> > You could, however, set up a AbortSlowAckConsumerStrategy to kick off
> > consumer if it takes too long processing the message, which might give
> > 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
> > a while back I didn't see a reason it would be different) you open
> > 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 …

Well, there is, if you write your code to treat interruption as a request
to exit the thread.  But it means you have to litter your code with with
checks for whether the Thread's interrupted flag is set.  So you can only
kill -9 if you implemented it manually (and correctly) ahead of time.

> --
> Founder/CEO
> Location: *San Francisco, CA*
> blog:
> … or check out my Google+ profile
> <>
> <>

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