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, > so I just sort of assumed any exceptions like that would result > in the message being not ack'ed, and the next one being picked > up. Restarting the process correctly picks up new messages from > RabbitMQ. > > Is there an undocumented best practice for handling SocketTimeoutExceptions? > I'd really very much like to continue consuming from the channel > :)
You did not post a stack trace to suggest anything. Socket exceptions in the RabbitMQ client should trigger a connection recovery. They also will be raised on the I/O thread so you cannot catch them from "user" code, e.g. ack-unless-exception. If SocketTimeoutExceptions is thrown by something else, it should be caught like any other exception. -- 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.
