Consider adding a function that checks for exchange existence and is a predicate

[DrTom]

If langohr-exchange/declare-passive is used to find out about an non existing exchange it will throw an IO Error, if there is no such exchange. This is cumbersome, a falsy return value would appear to me more useful.
At any rate, it will also close the used channel and renders it useless:
com.rabbitmq.client.AlreadyClosedException: channel is already closed due to channel error; protocol ...
This behavior is very annoying; in particular in the context of automatic connection recovery etc.

This is true for langohr 3.0.0-rc3.

[michaelklishin]

@DrTom this is how RabbitMQ Java client works. We can add a new function but it will have to accept a connection (to create a one-off channel). In any case, it is often not necessary to use passive declares. Just declare what you need with the expected properties, and voilà.

[michaelklishin]

Not only that's how the Java client works: it is how the protocol works, and it is way too late to change that.

[DrTom]

OK, I keep my work-around then for the time being.

[DrTom]

Although, there is a number of very undesirable effects related to the channel closing. From the docs:

Channels are typically long lived: you open one or more of them and use them for a period of time, as opposed to opening a new channel for each published message, for example.

Now, if I use declare-passive with a non existing exchange it will kill one of those long living channels. Consider the case that I used such a channel previously to subscribe to some queues.

Consumers last as long as the channel that they were declared on.

So, all my consumers are not consuming any more from this point.
It appears that somewhere things have not been thought through thoroughly. And it seems to be in the upstream java library. So, I suggest to remove declare-passive from the API, or at least put a big fat warning in the docs.

[michaelklishin]

@DrTom it's a pretty well known fact that passive declares should not be used on long-lived channels, and aren't necessary at all.

What are your expectations? It's too late to change the protocol, the broker and all client libraries out there. The best we can do is to provide a new function and suggest that people use regular declares where they can.

[DrTom]

Yes.