On Apr 17, 2015 6:36 PM, "Kevin Burton" <[email protected]> wrote: > > On Fri, Apr 17, 2015 at 4:38 PM, Tim Bain <[email protected]> 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>
