Re: [clojure-rabbitmq] SocketTimeoutExceptions terminates listening process

2014-05-21 Thread Michael Klishin


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 never have a handler throw exceptions to the langohr-lib,  
 but seeing as this can happen, and since it handles exceptions  
 just fine when :auto-ack is true (not demonstrated in the experiment,  
 but tested and verified), it seems that a consistent behaviour  
 on a reject should be to continue consuming.
  
 Is there something I'm missing?

What do you mean by ignored? Is the channel still open? Do you see 
basic.reject
on the wire? (e.g. using Tracer: http://www.rabbitmq.com/java-tools.html)

Throwing exceptions in delivery handlers is fine, it should not exhaust
consumer thread pool or anything like that.
--  
MK  

Software Engineer, Pivotal/RabbitMQ

-- 
You received this message because you are subscribed to the Google Groups 
clojure-rabbitmq group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [clojure-rabbitmq] SocketTimeoutExceptions terminates listening process

2014-05-21 Thread Michael Klishin


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. All of this 
 does makes sense as a default behaviour, but it doesn't seem to 
 be documented in langohr, so it took quite a while to figure out. 

Feel free to contribute doc improvements.

 - ack-unless-exception is confusing at best - it should not throw 
 the exception on but handle it to be valuable. Otherwise users 
 of langohr should just call .basicAck and .basicReject themselves. 
 I'd vote for just removing it from langohr.
 - The behaviour of langohr in the case where a handler throws an 
 exception is not documented in the doc-string of langohr.consumers/subscribe 

Screw doc strings. They cannot describe much because they can't be too
long. http://clojurerabbitmq.info should cover this, in both Working with Queues
and Error Handling and Recovery (the Queues guide can link to the Error 
Handling one, for example ).
-- 
MK 

Software Engineer, Pivotal/RabbitMQ

-- 
You received this message because you are subscribed to the Google Groups 
clojure-rabbitmq group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.