Can TopologyRecoveryException be simulated?

[Brian Marick]

We had a situation this morning where automatic topology recovery failed with this exception. I'd like to do something to my local rabbitmq server that provokes this exeption, to see if my fix works. Is there a way?

----
Let us go then, TMI,
When their profiles are spread out against the sky,
Like a patient etherized upon a table.

The Love Song of J. Random Profile

[Michael Klishin]

On 3 June 2014 at 23:13:00, Brian Marick (br...@getset.com) wrote:
> > We had a situation this morning where automatic topology recovery
> failed with this exception. I'd like to do something to my local
> rabbitmq server that provokes this exeption, to see if my fix
> works. Is there a way?

You can delete a queue and declare it with different attributes from out of process.
Then recovery will attempt to declare it with the original attributes and fail. 
--
MK

Software Engineer, Pivotal/RabbitMQ

[Brian Marick]

On Jun 3, 2014, at 2:16 PM, Michael Klishin <mkli...@gopivotal.com> wrote:

> You can delete a queue and declare it with different attributes from out of process.
> Then recovery will attempt to declare it with the original attributes and fail.

Thanks.

Small note for anyone doing this: delete the queue, redeclare it differently, then shutdown and restart the server.

[Brian Marick]

On Jun 3, 2014, at 2:13 PM, Brian Marick <br...@getset.com> wrote:

> We had a situation this morning where automatic topology recovery failed with this exception. I'd like to do something to my local rabbitmq server that provokes this exeption, to see if my fix works. Is there a way?

Am I correct to think that there's no straightforward way of hooking into the autorecovery mechanism to handle a TopologyRecoveryException? In our case, the Ruby apps were written to exit and restart upon any AMQP problem. When they started in the normal way, the topology problem didn't stop them and all was well.

The Clojure apps tried the auto-recovery, got stuck with the topology exception, didn't exit, and so were hung up until manually restarted. (Fortunately, only two real users were affected.)

So what I'd like is for the Clojure apps to System/exit upon that exception. But it's swallowed (and printed) by beginAutomaticRecovery in Connection.java.

Is the only option to hand-roll non-automatic recovery?

[Michael Klishin]

On 4 June 2014 at 00:43:52, Brian Marick (br...@getset.com) wrote:
> > So what I'd like is for the Clojure apps to System/exit upon that
> exception. But it's swallowed (and printed) by beginAutomaticRecovery
> in Connection.java.
>
> Is the only option to hand-roll non-automatic recovery?

All uncaught exceptions are eventually routed to ExceptionHandler (one per connection). Default
exception handler prints them out:

http://www.rabbitmq.com/releases/rabbitmq-java-client/v3.3.1/rabbitmq-java-client-javadoc-3.3.1/com/rabbitmq/client/ExceptionHandler.html

http://www.rabbitmq.com/releases/rabbitmq-java-client/v3.3.1/rabbitmq-java-client-javadoc-3.3.1/com/rabbitmq/client/impl/DefaultExceptionHandler.html

RabbitMQ Java client can use any exception handler you want but Langohr does not provide
a way to configure it yet:

http://www.rabbitmq.com/releases/rabbitmq-java-client/v3.3.1/rabbitmq-java-client-javadoc-3.3.1/com/rabbitmq/client/ConnectionFactory.html#setExceptionHandler(com.rabbitmq.client.ExceptionHandler)

Feel free to contribute this feature:

https://github.com/michaelklishin/langohr/issues/47 

[Brian Marick]

On Jun 4, 2014, at 3:31 AM, Michael Klishin <mkli...@gopivotal.com> wrote:

> Feel free to contribute this feature:
>
> https://github.com/michaelklishin/langohr/issues/47

I'll have the new guy do it when he starts in August.

[Michael Klishin]

On 4 June 2014 at 18:21:51, Brian Marick (br...@getset.com) wrote:
> > I'll have the new guy do it when he starts in August.

Hopefully it'll be done by then ;)