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
Code:
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,""}
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 with

Code:
@Bean
public RabbitBrokerAdmin rabbitBrokerAdmin() {
//create the admin and then declare the queue
}
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.

And with these
Code:
@Bean(name = "eventQueue2")
public Queue eventQueue() {
}
Because the name 'eventQueue' becomes the bean name, you don't need name="", simply
Code:
@Bean
public Queue eventQueue2() {
}
- Holly