On 21 May 2014 at 11:28:24, Thomas Kristensen (thomas.kristen...@uswitch.com)
wrote:
> > We're seeing SocketTimeoutExceptions in long running processes,
> with the consequence that no other messages are delivered to
> the subscribe function on that machine. We're doing ack-unless-exception,
On 21 May 2014 at 11:37:03, Thomas Kristensen (thomas.kristen...@uswitch.com)
wrote:
> > DefaultExceptionHandler: Consumer
> > langohr.consumers.proxy$com.rabbitmq.client.DefaultConsumer$ff19274a@31bdf573
> >
> (amq.ctag-GGj0_JfnXHvzpI8YHuHY3w) method handleDelivery
> for channel
> AMQChann
On 21 May 2014 at 11:55:46, Thomas Kristensen (thomas.kristen...@uswitch.com)
wrote:
> > Regardless of my handler throwing an exception or not, I would
> expect the same handler to be invoked on the next message coming
> in. That's what I find confusing. ack-unless-exception does
> nothing
Thanks for the clarification - I decided to spike the problem out to get a
better understanding of what is going on. I think my conclusion is that my
understanding of what ack-unless-exception does is flawed. My understanding
was that, if a handler threw and exception, the message wouldn't be ack'e
On 21 May 2014 at 12:49:19, Thomas Kristensen (thomas.kristen...@uswitch.com)
wrote:
> > My understanding was that, if a handler threw and exception,
> the message wouldn't be ack'ed, but be put back on the exchange.
> That does not seem to happen, and when qos is 1, we seem to get stuck,
> as
Hi Michael,
Once again, thanks for all the explanation. I've experimented a bit this
morning, and I've isolated what I find weird.
If you run
https://github.com/tgk/langohr-consumer-dies-spike/blob/master/src/spike.clj
you'll notice that the message gets rejected as we'd expect when the
excepti
On 21 May 2014 at 16:58:38, Thomas Kristensen (thomas.kristen...@uswitch.com)
wrote:
> > you'll notice that the message gets rejected as we'd expect
> when the exception is NOT re-thrown, but the reject seems to be
> ignored in the case where we re-throw. You could argue that you
> should
You are right, the channel has been closed by me throwing on the exception.
I attached a debugger and traced it to line 106 of DefaultExceptionHandler
which closes the channel in handleChannelKiller. All of this does makes
sense as a default behaviour, but it doesn't seem to be documented in
langoh
On 21 May 2014 at 19:15:50, Thomas Kristensen (thomas.kristen...@uswitch.com)
wrote:
> > You are right, the channel has been closed by me throwing on the
> exception. I attached a debugger and traced it to line 106 of
> DefaultExceptionHandler
> which closes the channel in handleChannelKiller
