We do indeed need to handle scenarios where an installation (Erlang/Rabbit) has multiple nodes and for each node we can have multiple virtual hosts and then the fun begins. For the moment Mark Pollack's suggestion works with @Qualifier. That said, this does not allow for an application to dynamically adapt to newly-created virtual hosts > exchange, queues, etc in runtime. I'm working on this but it's a prototype.
I have definitely seen
You simply don't have the right queue and vhost matched up as it says. If you need to initialize it once you can create it in your configuration withCode:Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method<channel.close>(reply-code=404,reply-text=NOT_FOUND - no queue 'LWESEvents' in vhost 'TDB-Dev',class-id=50,method-id=10),null,""}
Note that if you are using that queue as the main queue in your SimpleMessageListenerContainer bean, you will need to insure that queue exists in the node's virtual host prior to creation of the listener.Code:@Bean
public RabbitBrokerAdmin rabbitBrokerAdmin() {
//create the admin and then declare the queue
}
And with these
Because the name 'eventQueue' becomes the bean name, you don't need name="", simplyCode:@Bean(name = "eventQueue2")
public Queue eventQueue() {
}
- HollyCode:@Bean
public Queue eventQueue2() {
}
