Architecture of a web application using message queues

Question

I have a java web application which uses some form of custom message queuing via a database table (EmailQueue) to queue delivery of emails. The application is deployed on Tomcat and uses Quartz jobs which polls for new entries in the EmailQueue table to send.

I now need to add queuing of a few other types of jobs and messages (notifications, sms, etc.) and am therefore looking into using a proper message queue (RabbitMQ, ActiveMQ, etc.) instead of the database. This is motivated by a few articles on the matter which argue a database should not be used as a queue.

I haven't completely gotten my mind wrapped around the whole ecosystem however and would appreciate some guidance. Specifically:

• In the context of web applications, does the message queue broker usually run as its own process, like the database does? I need the messages to be persistent in case of server restarts.
• Should the message queue consumers be deployed as servlets in Tomcat or as standalone java applications? I'm especially interested in the manageability of it all (i.e. start/stop instances, configuration, monitoring) Related question and email thread.

Answer 1

1. In the context of web applications, does the message queue broker usually run as its own process, like the database does? I need the messages to be persistent in case of server restarts.

The message queue broker typically runs as its own process. With RabbitMQ, your producers can define the messages to be persistent.

2. Should the message queue consumers be deployed as servlets in Tomcat or as standalone java applications? I'm especially interested in the manageability of it all (i.e. start/stop instances, configuration, monitoring) Related question and email thread.

Regarding my question on a similar topic here, I ultimately deployed my consumers as Tomcat applications, which did provide me with the manageability that I too was looking for. This allowed me to write servlets for monitoring and managing the queues.

This solution works for scalability, also, which is important with messaging & queuing. I was also able to easily scale the number of consumers on the fly by taking a snapshot of the server running Tomcat (I was using Amazon EC2 instances) and deploying that snapshot onto a new instance. I had configured Tomcat to start automatically as a service so that when the new instance started, the consumer .war files would deploy and automatically start consuming.

Be careful with the threading, however, as discussed in my question. I had initially run into problems with stopping Tomcat.

You can also achieve manageability with consumers as standalone Java applications using JMX, however. Using JConsole, you can remote into your Java applications and query/update parameters during runtime. Many monitoring programs, such as Zabbix, can connect to applications using JMX.

If you enjoy web development and building your own web applications, I would go the Tomcat route. Hope that helps.

Answer 2

A good choice! Message oriented middleware is already written and will save you some trouble - instead of reinventing the wheel.

1. In full profile Java EE servers, the messaging system is usually an integrated part. For tomcat, look at TomEE+ or similar for an idea of how ActiveMQ and Tomcat is working together.

ActiveMQ can easily be deployed either as an embedded broker inside your servlet or as a standalone process. It's just a matter of manageability and what you prefer. I would consider a standalone ActiveMQ, since you might want to add more Tomcat servers in some scenario, and point both to the same ActiveMQ server. RabbitMQ is not running on Java, but an Erlang platform - so that is something different.

1. That is up to your architecture and what you feel is more comfortable to manage. Deployed as servlets seems like a reasonable approach as you might have monitoring and other things in place already.

You could as well run the mailing service inside ActiveMQ itself. You can easily embed spring beans in the ActiveMQ configuration - or, preferably, run Camel Routes with mail functionality that does these kind of things with simple XML configuration. If you have a lot of logic in the mailing consumer, it should probably be kept as a part of the servlet application.