2
votes

I currently need to utilize three vhosts for this application. I am only receiving messages over one as a consumer, and the others for RPC calls. Currently I am using CachingConnectionFactory that I have subclassed one for each virtual host. Then I am making each of those subclasses beans. I can then of course grab the connection factory to create the RabbitTemplate for the correct vhost instance.

I saw in the documentation about the AbstractRoutingConnectionFactory but wanted to know if there are any reasons I should refactor my currently working code. I want the most maintainable and perfomant solution, not the "easiest" one.

Thanks!

1

1 Answers

4
votes

I am not sure why you felt it was necessary to subclass the CachingConnectionFactory you can simply declare multiple factories...

<rabbit:connection-factory id="default" host="localhost" />

<rabbit:connection-factory id="foo" host="localhost" virtual-host="/foo" />

<rabbit:connection-factory id="bar" host="localhost" virtual-host="/bar" />

Whether or not you using a routing connection factory (e.g. SimpleRoutingConnectionFactory) depends on your application needs. If you don't use it you would need 3 RabbitTemplates and decide which one to use at runtime.

With a routing connection factory, the RabbitTemplate can make the decision based on the message content with a send-connection-factory-selector-expression.

There's not really a lot of difference except the second decouples your application from the decision. For example, you can set a message header customerId before sending (or during message conversion if you're using a convertAndSend method) and use a selector expression such as @vhostFor.select(messageProperties.headers.customerId).

If you later add a new vhost you wouldn't have to change your main application, just your vhostFor lookup bean to pick the right vhost.