Discussions

General J2EE: Preferred JMS server?

Bookmark and Share Get thread feed

  1. Preferred JMS server? (10 messages)

    We are implementing an application with JMS for the first time. The intent is to use JMS to receive sensitive/secure information from a Tomcat 5 web server through a firewall and make it available to some application server to process.

    Not sure if the application server processing the messages will be the same server as the JMS server.

    My question: Given that we are using an existing Tomcat web application which uses POJO's (Plain Old Java Objects) and that we have a constricted time line (2 weeks) to implement, what JMS server does the community endorse as:

    1) The fastest/simplest to implement/integrate with Tomcat
    2) The best documented on line
    3) Having the fewest "issues" (IE XML Hell, fewer/no management features, etc)

    I am aware of several servers available (OpenJMS, JBoss, Spring, Sun, etc). If you have worked with these or others, I would love your feedback. Also interested in "watch out for this!" issues and security/encryption tips

    Thanks!
    Reply to this

    Threaded Messages (10)

  2. Preferred JMS server?[ Go to top ]

    We are implementing an application with JMS for the first time. The intent is to use JMS to receive sensitive/secure information from a Tomcat 5 web server through a firewall and make it available to some application server to process.Not sure if the application server processing the messages will be the same server as the JMS server.My question: Given that we are using an existing Tomcat web application which uses POJO's (Plain Old Java Objects) and that we have a constricted time line (2 weeks) to implement, what JMS server does the community endorse as:1) The fastest/simplest to implement/integrate with Tomcat2) The best documented on line3) Having the fewest "issues" (IE XML Hell, fewer/no management features, etc)I am aware of several servers available (OpenJMS, JBoss, Spring, Sun, etc). If you have worked with these or others, I would love your feedback. Also interested in "watch out for this!" issues and security/encryption tipsThanks!

    I'd recommend ActiveMQ

    http://activemq.org/

    Its generally the easiest to embed in a JVM/Tomcat, has the most features and is the fastest open source JMS server. I'd also recommend using Spring too for dependency injection and configuration.

    To see how ActiveMQ integrates cleanly with Tomcat, JNDI and Spring try these links...

    http://activemq.org/Tomcat
    http://activemq.org/JNDI+Support
    http://activemq.org/Spring+Support

    e.g. the last page shows cleanly how to embed a JMS server inside Tomcat if you wish. By default ActiveMQ will create a peer based network of embedded JMS servers in each Tomcat. Though there are plenty of different topologies you can choose such as federated or peer networks with clusters etc.


    If you're POJO based, you might also wanna look at using Lingo

    http://lingo.codehaus.org/

    Which supports POJO based remoting using Spring Remoting and JMS, which works great with ActiveMQ.

    James
    LogicBlaze
    Reply to this Reply to original

  3. Preferred JMS server?[ Go to top ]

    I'd recommend ActiveMQhttp://activemq.org/Its generally the easiest to embed in a JVM/Tomcat, has the most features and is the fastest open source JMS server.

    We are doing some robust stress load test with various JMS servers. The default ActiveMQ did not performed very well. It has quite a number of timeout while receiving the messages. Neither did Mantaray and SwiftMQ performed very well. When the tests were done repeatedly, the performance drops. SwiftMQ trial was not able to complete because it only allow 30 minutes of running. (sorry we have to give SwiftMQ a miss).

    We have done the test with Joram, interestingly, although it is not the fastest at the beginning, it managed to stay consistent throughout the test and it complete the tests without any timeout. The Joram mailing list is also very responsive and fast. If money is an issue, then perhaps Joram is a better choice (as you know these guys will support us).

    SonicMQ was amazing fast, but not it has segmentation fault and we are not able to restart it (have to wait for a long time for eval at sonicsoftware dot com to reply and they seems to ignore us when we do not represent big corporations).

    We are currently testing iBus. The LE only allows 2 connections. We request for trial of more than 2 license, the CEO replied promptly and is in the progress of giving us 50 connection trial license, something that is worth mentioning. iBus seems to be very efficient in memory and performance too.

    When we do a simple queue test of continuously sending messages, it was able to accept up to 931,203 messages (may defer depends on the size of the message). Joram was able to accept up to 10,852 messages. SonicMQ only able to accept less than 2,000 messages. These test are based on default settings.

    We have not tried OpenJMS, JBossMQ yet.
    OpenJMS is still beta if I am not wrong. JBossMQ is undergoing changes I believe.

    All in all, I think robustness, reliability and support is important.
    Vendors can claim speed, but that should be tested robustly, in some cases, speed becomes slower after N-runs. When messages get lost, support is the next best thing we can count on.

    Huey
    PS: I do not represent any JMS vendor.
    Reply to this Reply to original

  4. Preferred JMS server?[ Go to top ]

    SonicMQ was amazing fast, but with heavy load it has segmentation fault and we are not able to restart it after that (have to wait for a long time for eval at sonicsoftware dot com to reply and they seems to ignore us when we do not represent big corporations).

    To replicate the problem, do a simple looping of message sending to a queue. It should pause after a while when it reach it's max queue size. Start the management console, change the queue size to about 1,000,000. The paused queue sending program should continue until the backend sonicMQ server went out of memory. After which it will not be able to restart.

    Not sure how to revive back SonicMQ to the original stage, I uninstall and reinstall it back (takes quite a while like Windows OS). And then you could restart it like brand new.

    This could be a real life issue if the application using JMS does not remove the message in the queue on time. SonicMQ's default is really small (maybe that is why it is fast). Imagine everything else gets pause because of this. Enlarging the queue size could result in segementation fault.
    Reply to this Reply to original

  5. Preferred JMS server?[ Go to top ]

    We are doing some robust stress load test with various JMS servers. The default ActiveMQ did not performed very well. It has quite a number of timeout while receiving the messages. Neither did Mantaray and SwiftMQ performed very well. When the tests were done repeatedly, the performance drops. SwiftMQ trial was not able to complete because it only allow 30 minutes of running. (sorry we have to give SwiftMQ a miss).

    Hi Heuy,

    Thank you for the input. We at Coridan would be more then happy to help you resolve the problem you are experiencing with the MantaRay. We currently don't have any open bug on this subject. Please contact us directly for assistance.

    Best Regards,

    Alon Eizenman
    support at coridan dot com
    Coridan
    Reply to this Reply to original

  6. Preferred JMS server?[ Go to top ]

    SwiftMQ trial was not able to complete because it only allow 30 minutes of running. (sorry we have to give SwiftMQ a miss).

    Beside the restricted 30 minute eval version you can download from our web site, you can also request a 30 days eval version (mentioned on our web site). We have to generate it for you so that's the reason why you must request it. Just send an eMail to presales at swiftmq dot com.

    -- Andreas (SwiftMQ)
    Reply to this Reply to original

  7. Active MQ[ Go to top ]

    Once upon a time we tested ActiveMQ and as I remmember I failed when we had long running processes and I couldn't manage to solve the problem on ActiveMQ.
    Reply to this Reply to original

  8. Mule MQ[ Go to top ]

    MuleSoft just released a new JMS Server, Mule MQ, which performs faster than ActiveMQ in many use cases. It's supported by MuleSoft, the creators of Mule ESB.
    Reply to this Reply to original

  9. JBossMQ testing-slows down[ Go to top ]

    My client requires a JMS Server that can support queuing without receiver for about 1080000 messages of about 2kb each(100 messages per second for 3 hours). I tested JBoss MQ. It starts to slow down after some time. Also if I have to restart the JBoss server after a lot of messages have been sent, it gives me an outOfMemory error cause it tries to load all the messages in the database at startup. This is a known issue to JBoss but there is no fix yet. We are also testing ActiveMQ. But the message throughput falls to 1 message/sec after some time. We are trying to figure out if there is a way to tune it.
    We prefer an open source JMS provider so Active and JBoss will fit well if we can find a way to solve the problems. ActiveMQ is very very fast with the receiver running.
    Reply to this Reply to original

  10. JBossMQ testing-slows down[ Go to top ]

    Dear Saurabh,

    The best JMS for this purpose is FioranoMQ.
    I tried continuously sending more than 4,000,000 messages without receiving it and it is still running. Restarting it also works.

    When I try on SonicMQ with the default, it will stop after 1,964 messages. When I push up the queue size to 1,000,000 it went out of memory at 621,200 messages. When you restart it, it give you segmentation fault. I was suggested to push up the memory max to 512 and it took about 42 minutes to recover.

    If you start SonicMQ with a max memory of 512, i can send up to 1,933,174 messages, but it will slow down your machine tremendously. SonicMQ support refuse to support me with my GMail email. Not very good value for money for a paying JMS.

    SwiftMQ can accept up to 931,203 messages.

    Joram can accept up to 10,852 messages. No out of memory, it only stops there and when you start to clear your messages from the queue, it continues.

    I could not really finish testing the rest. It will be interesting for JMS vendors to publish results of such test.

    I think this test is relevant because there might be cases where your application receiving the JMS went down and then it bottleneck everything or it kill your JMS server which is totally unacceptable for any application.
    Reply to this Reply to original

  11. Preferred JMS server?[ Go to top ]

    Hi !

     

    I wonder why you make speed tests on a full queue complaining on slow speed when 1mio messages in queue. In production, when applications are properly written, queue should have small size of messages currently in store. For me the most important is how many messages/s can JMS server accept and how fast it delivers it.

    Reply to this Reply to original