activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
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" <burton@spinn3r.com> wrote:
>
> On Fri, Apr 17, 2015 at 4:38 PM, Tim Bain <tbain@alumni.duke.edu> 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.

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
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.

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
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 …

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 Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
> <http://spinn3r.com>

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