Add option to bind queue/exchange passively about op-rabbit HOT 8 CLOSED

Here, definitely. These discussions are, in theory, easier to find for the general public.

This is a good idea, and probably best achievable by creating additional subscription strategies. The Subscription class has an initialized future which could be used to communicate failure to bind.

from op-rabbit.

I added support for passive bindings, but now it just keeps failing and retrying (without even pausing). However, I think this is a separate issue of how to handle subscription failures. The same problem can occur with the existing bindings if you try to bind to an existing queue with "wrong" parameters (durability, auto-delete, etc.).

from op-rabbit.

FWIW, this incessant retrying behavior has caused me some grief today as well.

My use case is the opposite of @talp-traiana: I want to use an existing non-autodelete queue if it exists, or create an autodelete one if it doesn't (because the client app is a good citizen); but the effect is the same. Would really like to be able to control the binding behavior and handle failures explicitly.

from op-rabbit.

@unthingable It sounds to me like you'd like to do a custom binding, or compose bindings together using something like an orElse operator?

I'm not happy with the present passing of error-logging et. al via implicits on the consumer binding, and am planning to change it. After that point, it'll be easier to define custom bindings.

from op-rabbit.

@timcharper I'd like to at least be able to check for queue presence and handle binding error explicitly. Doing it the opinionated way would require supporting at least three clearly selectable behaviors:

1. Expect the queue to exist, fail otherwise (@talp-traiana's case)
2. Expect the queue to not exist, fail otherwise
3. Use the queue if it exists (ignoring supplied parameters), otherwise create with supplied parameters.

In general, setting up queues and bindings is too a nontrivial affair to wrap all of that in something like a single topic() or even queue() directive. I can see their intent of making things easy, but in practice they are having to make too many decisions to cover enough use cases.

from op-rabbit.

FYI - @talp-traiana the above patch, slated for M12 release, addresses the infinite retry. Retry will only occur on connection errors.

from op-rabbit.

FYI - M12 release went out. v1.0.0-M11...v1.0.0-M12

from op-rabbit.

Marking as resolved, since this now supported.

@unthingable can you open up an additional issue for your request?

from op-rabbit.