Multiple ConnectionFactory and multiple SimpleMessageListenerContainer best practices

[Kaps]

Hi,

I have below queries on Spring AMQP:

We have one CachingConnectionFactory per virtual host. We are creating CachingConnectionFactory dynamically and are not defined in app context, we are self maintaining them in a map.

Now CachingConnectionFactory is needed by three components:
1) AmqpAdmin/RabbitTemplate
2) SimpleMessageListenerContainer
3) *MessageSender classes that uses RabbitTemplate and extends RabbitGatewaySupport

1) How would you like to recommend configuring SimpleMessageListenerContainer and *MessageSender classes? because single *MessageSender class can send messages to any virtual host thus *MessageSender should know which CachingConnectionFactory to use dynamically. We have *MessageSender as singleton.

2) Similarly, how would you like to recommend configuring SimpleMessageListenerContainer while receiving messages? because SimpleMessageListenerContainer should know about the appropriate CachingConnectionFactory. One SimpleMessageListenerContainer is not gone work here.

3) What are the areas we need to keep in mind while creating such a design?

Our initial understanding here is that if we have five CachingConnectionFactory then we need to end up with five SimpleMessageListenerContainer. But the notable thing here is that we dont know how many CachingConnectionFactory to create on app startup. These are lazily created.

Thanks in advance

[Gary Russell]

1. If you want some form of dynamic sender, then don't subclass RabbitGatewaySupport, use your own support class that supports multiple RabbitTemplates.

2. You need a separate listener container for each connection factory.

You could define your factory and listener container in its own config file; use property placeholders for the configurable details; instantiate the context and make the main context the parent context; that enables each child to reference beans in the main context. You can pass in properties for the placeholders using the Spring 3.1 environment support...

ConfigurableApplicationContext ctx = new ClassPathXmlApplicationContext(
		new String[] { "/META-INF/spring/integration/configurable-listener-context.xml" },
		false,
		mainContext);

StandardEnvironment env = new StandardEnvironment();
Properties props = new Properties();
props.setProperty("foo", "bar");
...

PropertiesPropertySource pps = new PropertiesPropertySource("ftpprops", props);
env.getPropertySources().addLast(pps);
ctx.setEnvironment(env);
ctx.refresh();

[Kaps]

Thanks a lot Gary, Regarding your first point we also think that we should not extend RabbitGatewaySupport, rather create our own support class or achieve the same (multiple rabbit templates) by some other design.

[EdwinDhondt]

Is it possible to have multiple listener-container, each pointing to the same connectionfactory ?

[Gary Russell]

Yes; that is a completely normal situation.

[EdwinDhondt]

If it is ok to have multiple DMLC listener-containers (each referencing the same queueconnectionfactory) then is it also ok if each of those DMLCs contains listeners listening on the same queue ?
Eg. DMLC-1 contains listener01 with destination jms/queue01 and DMLC-02 contains another listener pointing to the same destination jms/queue01.
Is that a configuration that will work reliably ? Is it advisable, will a particular message only be consumed once-and-only-once ?

[Gary Russell]

This is the AMQP forum; you appear to be talking about JMS (there is no DMLC in spring-amqp and you use jms in your queue names).

Regardless (JMS Vs. AMQP), it is a function of the broker to deliver a message to only one consumer. The fact both consumers are using the same connection is irrelevant.

[EdwinDhondt]

Sorry, I posted to the wrong forum, I'll follow this up on the JMS forum.