Feature: dynamic queues/bindings registry

[bojanv55]

This is related to dynamic queues and their registration in runtime.

So far, if queue is declared as a @bean it will be detected by RabbitAdmin and declared in case there is a connection problem (or rabbit failover etc.). But in case that it is created in runtime, it has to be manually registered as a singleton bean, otherwise on rabbit failover, queue will not exist anymore in rabbit and listener container will fail.

I guess this should be taken care of? E.g. when registering the queue to container it should be registered as a bean, so rabbit can later redeclare if needed. Just don't know what to do with bindings, since those also have to be in place on Rabbit failover.

Other option is to have something like:

ContainerDeclarables cdec = new ContainerDeclarablesBuilder
                .container(messageListenerContiner)
                .declarables(declarablesSupplier);

where you would have all declarables which would be bound to container at a runtime, and at the same time handle bean registration at runtime and expose methods as removeQueue (that would remove the queue from registry and unbind it from container) etc.

What do you think about this?

[garyrussell]

It's not clear what you are trying to achieve. What is wrong with registering the bean with the application context?

And, as you say, the queue alone is not enough and the container has no knowledge of the exchange and/or routing key.

I could envision something like CompoundDeclarable containing queue, exchange and binding and

RabbitAdmin.declareCompound(String beanName, CompoundDeclarable dec) {...}

Since the admin has a reference to the application context it could register the bean automatically.

But I question the value, given that you can register the bean(s) yourself.

[bojanv55]

Was thinking if possible to decrease code you need to write, but to have it already in amqp-spring lib.

So use case is to register queue to container at runtime as easy as possible. This queue will possibly be bound to some exchanges. I guess exchange in runtime is not that common requirement, but queue and binding is.

So far container.addQueue only adds queue to container, but it is not tracked by context and not automatically declared.

So, something like container.addQueueWithBindings(Map<Queue, Set<Binding>> qb) that would automatically register queues and bindings with context and declare it with rabbit admin (and re-declare as needed) and start consuming from queues in runtime.

[artembilan]

I don't think we should think about mixing responsibilities. The container is really not about declaration and registration. It is only for connecting to the specified queue and consuming messages.
A declaration, registration and binding is really up to a RabbitAdmin.
I think we need just add an additional functionality into a RabbitAdmin something like declareAndRegistrerQueue(). So, target application will be able to declare a queue at runtime and have it registered as as a bean.
We also could do a revers logic like BeanPostProcessor to catch runtime beans and declare them on RabbitMQ, but that is not going to be as high level API like the mentioned single function like declareAndRegistrerQueue().

Anyway I'm against adding such a functionality into a listener container...