This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Multiple RabbitAdmin instances force dubious declarations.

I'm a little confused on the queue declaration policy for spring rabbit dist of amqp. Documentation suggests following

2.12.1 Automatic Declaration of Exchanges, Queues and Bindings

The RabbitAdmin component can declare exchanges, queues and bindings on startup. It does this lazily, through a ConnectionListener, so if the broker is not present on startup it doesn't matter. The first time a Connection is used (e.g. by sending a message) the listener will fire and the admin features will be applied. A further benefit of doing the auto declarations in a listener is that if the connection is dropped for any reason (e.g. broker death, network glitch, etc.) they will be applied again the next time they are needed.

However, currently there is no mechanism for assigning a queue to a particular connection factory, so if I wanted to declare a queue on a particular broker with RabbitAdmin, it is currently not possible.

Depending on your usage, you may need to define the queues etc in the main and the sub-contexts; in which case, simply omit the rabbit admin in the main context and do all the declarations in child context.

Obviously, ForceDeclarations would have to be a bit more sophisticated than this, in order to reconnect/redeclare after a failure. Or, you can add a listener container that listens on a dummy queue - it wiill automatically reconnect, causing the redeclare.