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. So you've gotta write rock-solid code to make sure you either ack or rollback in all situations; if that's not possible for any reason, use one of the auto-acking modes instead. And if you want your message handler to time out after some amount of time, you'll need to do that on the client side.
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. 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. Tim On Fri, Apr 17, 2015 at 4:49 PM, Kevin Burton <[email protected]> wrote: > Nevermind on this one. I think the issue is that there’s no really solid > way to test this. > > I don’t know enough about the JMS internals. It seems like if I keep the > session,consumer open, that the client acknowledge never times out. I gave > it ten minutes and it never attempted to hand out the message to a new > consumer. > > I guess I would have to do something like kill -9 a Java proc to really > test failure. > > On Fri, Apr 17, 2015 at 2:06 PM, Kevin Burton <[email protected]> wrote: > > > It looks like redelivery variables work if you call session.rollback() … > > but not if you just never send an acknowledgment when running with > > CLIENT_ACKNOWLEDGE mode. > > > > http://activemq.apache.org/redelivery-policy.html > > > > It seems like it’s exactly 2000ms no matter if I set > > initialRedeliveryDelay or redeliveryDelay. > > > > So there must be some other variable I’m not seeing. > > > > I did an RTFM and couldn’t find anything. So I must be blind or the > > documentation is hidden :-P > > > > -- > > > > 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> > > > > > > > -- > > 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> >
