ActiveMQ standalone server deployment or embedded in a Spring Webapp

Question

I have a requirement to design an application which notifies/publishes, its subsystems to send out emails. I have planned to do that using jms publish/subscribe (topic) messages

The visibility for now , there would be 20 to 30 subscribers and the number of messages that would be published would be in the range of 30000 to 50000 messages per day.

I have planned to use ActiveMQ JMS+Spring 3+Tomcat 6 implementation Questions

1. I am fairly new to JMS , i would like to know if the above load is high?

2. Do we really need a separate ActiveMQ deployed on to a server or is it sufficient that we use an embedded ActiveMQ in the Webapp?

3. What are the advantages/disadvantages of separate ActiveMQ server / embedded one?

Answer 1

First note, your message volume is pretty small as things go. You could really use either and whatever is easiest to maintain would probably dictate your choice.

Expanding on Petter's comment on restarts one thing to consider is the number of other machines that will be connecting to the broker.

Clients

If you have 100 machines connected to the broker then every restart of Tomcat w/ embedded ActiveMQ will break 100 connections that all need to reconnect. ActiveMQ supports reconnecting so can work out fine, but it can add some needless delay to message flow while everyone gets reconnected and sometimes a couple clients will fail to reconnect and you have to manually kick them into action.

With a standalone broker and say 100 clients, you can restart your Tomcat server as often as you like and only ever break the one connection from the broker to Tomcat. That can be very nice.

If you have just one client -- the Tomcat server itself -- then hands down go embedded and use the in-vm transport.

Memory

Another factor is memory. We use ActiveMQ in Amazon EC2 on a t1.micro which only has 613MB of memory which is pretty small. It's cheaper to run two t1.micros (one for ActiveMQ and one for Tomcat) than one m1.small that has both.

But again, the number of clients is a factor. If there are no other clients than Tomcat, running one m1.small and keeping everything in the same vm is probably way better.

FYI

If Tomcat and ActiveMQ are your primary targets you should consider Apache TomEE Plus which is Tomcat with ActiveMQ already integrated.

All the jars are there, everything is setup by default with an embedded ActiveMQ broker using the local transport that Petter talks about. You can easily configure it to use a standalone ActiveMQ broker as well. It also has JavaMail built in which sounds like it might be useful to you.

So you can skip the setup part and just get straight into writing your app. For example, if you were to create this single Servlet and put it in a war with no other jars or classes, it would work:

@WebServlet("/hello-world")
public class MyServet extends HttpServlet {

    @Resource(name = "foo")
    private Topic fooTopic;

    @Resource(name = "bar")
    private Queue barQueue;

    @Resource
    private ConnectionFactory connectionFactory;

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        //...

        Connection connection = connectionFactory.createConnection();
        connection.start();

        // Create a Session
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

        // Create a MessageProducer from the Session to the Topic or Queue
        MessageProducer producer = session.createProducer(fooTopic);
        producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

        // Create a message
        TextMessage message = session.createTextMessage("Hello World!");

        // Tell the producer to send the message
        producer.send(message);

        //...
    }

}

Here is also a Getting Started Video which shows setting it up in Eclipse via the Tomcat adapter.

Answer 2

If the load is high or not is hard to tell. It really depends on the size of the messages and if you are using persistent messages and transactions, or not. Say they are just around a few 10KB, you should be doing just fine with one server.

The question of embedding vs stand alone is a great question. Let me put up a few pros/cons I am thinking about.

Stand alone: Pro standalone:

• If you have other applications than your spring app that will use the ActiveMQ, then a restart of you application would affect ActiveMQ as well. This does not seem to be the case here, though.

• The other way around, you could upgrade the ActiveMQ installation without turning of your spring application, if uptime is critical.

Cons Standalone:

• More to think about (another installation) to monitor, operate etc.

I like the embedded solution, if this is one application internal anyway. ActiveMQ is great to embedd. If your application needs to be scaled out, you could easily just fire up another server with your spring app. and cluster the ActiveMQ instances with a line of XML, and there you go.

Another Pro for the embedded solution is that the transport between Spring and ActiveMQ can be JVM internal, so messges will not travel through the TCP/IP stack rather be a memory copy. That will speed your application up.