[rabbitmq-discuss] Container for RabbitMQ Listener/Consumer (Java)

[Tim Watson]

Hi Antony,

On 01/23/2013 12:14 PM, antony wrote:
> I will try to re-phrase the question.
>
> So far we have been using a stand alone Java program that listens to a
> particular queue in an infinite while loop for all the POCs as mentioned in
> all the examples.
>
>     while (true) {
>          String response = null;
>
>          QueueingConsumer.Delivery delivery = consumer.nextDelivery();
>
> What I want to understand is how the listeners are set up/deployed in a
> production environment? Do we need to have container like Spring ? How
> exactly Scalability, HA are handled ? Hope to get a response.

How you choose to deploy components of your own application is entirely 
up to you. The fact that your application components interact with a 
messaging server is orthogonal to questions about deployment topology 
and/or the use of Spring. Here's my perspective on this.

1. If you need an application server, then use one.

This won't have any effect on the broker (which is an external program 
running on another machine) but if your application can benefit from 
running in a container then go for it. Whether your consumer code is 
running in a container or not, you'll still need to write code to 
interact with the broker, handle acks and/or confirms, and so on. The 
container is a deployment environment which may (or may not) offer some 
useful services to the application, but the RabbitMQ java client will be 
completely unaware of these and therefore it's up to you to choose 
whether they make sense for your particular use case.

2. Spring is also orthogonal  ....

... at least to some extent. The Spring AMQP and Spring messaging layers 
offer many useful features that you may wish to take advantage of, but 
they're not magic - simply re-usable code that has been well tested. 
There's no reason why a standalone Java application that uses the 
RabbitMQ Java client directly shouldn't be just as stable and reliable 
as an application written using Spring, but using Spring might make it 
easier to achieve those goals.

3. Scalability/HA are the responsibility of the broker ....

to some extent. :)

Actually you'll want to think carefully about your messaging topology 
and the way in which producer and consumer applications interact with 
the broker. Connecting to a cluster might complicate the design of your 
application, with regards issues such as connecting to different nodes 
and so on. In terms of Scalability - how your application performs, and 
appears to perform (from an outside perspective) can depend on a lot of 
different factors. It's impossible to offer any advice without knowing 
more specifics, but in general you should be looking at what the broker 
offers (in terms of message delivery guarantees for HA and in terms of 
performance profiles with various different settings and under various 
topologies) and make your design decisions based on there.

Running your application in a container won't change the broker's 
message delivery guarantees or performance profile at all, but may offer 
other benefits. Using Spring won't 'enable' HA or improve scalability by 
itself either, but some features (such as auto-reconnect for 
disconnected consumers) may be useful to your application and improve 
its reliability.

Hope that helps. I'd suggest spending a good amount of time in the 
documentation to make sure you understand all the features Rabbit has to 
offer, and then of course feel free to drop back here and ask any 
specific questions. :)

Kind regards,
Tim