jakarta-eejmsactivemq-classicsetup-deployment

ActiveMQ standalone server deployment or embedded in a Spring Webapp


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?


Solution

  • 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.