[ACCEPTED]-Which JMS implementation do you use?-jms
Before delving into JMS, consider AMQP as 23 well - might be a new standard. JMS providers 22 I worked with (in varying degrees):
TIBCO 21 EMS - very quick and robust, good API support, Java 20 friendly, native C API exists. Best commercial 19 choice I've used.
Websphere MQ (and its JMS 18 implementation) - so, so. Pub/sub not exactly 17 quick, many configurations options and choices 16 are 'strange' and overly complex from the 15 long history of that product. Just look 14 at the amount of documentation...
Solace 13 JMS - very high throughput (the JMS broker 12 is built in hardware !), good choices of 11 connecting protocols (MQTT, AMQP, XML over 10 http as admin protocols)
Fiorano MQ - used 9 to be agressive in marketing but lost a 8 lot of market share, maturity concerns
Sonic 7 MQ - solid product, also supports a C API
Active 6 MQ - if you want to go with an open-source 5 product (unexpensive support, great community, limited 4 add-on products, limited enterprise features) this 3 is probably your best choice. Works out 2 of the box and is the backbone of several 1 tools like Apache Camel, for example.
We rely on AMQ (5.1) via the Camel framework, and 2 there haven't been any issues. AMQ 4 was 1 a tad more fishy.
WebLogic JMS provider when using WebLogic. Works 1 great.
TIBCO EMS. It's a commercial message service with 2 Java/JMS, C, .net, and other bindings for 1 it.
Sun's Open source OpenMQ (https://mq.dev.java.net/). You can get 7 free and paid support for the same.
See this 6 blog post about some comparison with ActiveMQ, etc 5 -- http://alexismp.wordpress.com/2008/06/06/openmq-the-untold-story/.
I've heard that OpenMQ is more stable.
ActiveMQ 4 is more flexible. as in, you can use it 3 with more languages. There are probably 2 more people on ActiveMQ's mailing list than 1 OpenMQ.
In one of the recent projects I was in we 9 used Sonic MQ. Good overall implementation with 8 good bindings to .NET.
We had a little of 7 scalability problems, but I have to admit 6 that the scalability requirements were very 5 strict: if I can recall correctly, something 4 like 20,000 messes a second with no delays 3 allowed between the 200 different clients 2 (every client had to receive every message 1 at the same time).
I've used JBossMQ, which comes with JBoss 9 app server up to version 4, and which is 8 solid but limited. JBoss Messaging was 7 the replacement, comes with JBossAS 5, and 6 is a huge improvement.
ActiveMQ I have a 5 real dislike for. The developer(s) seem 4 to have gone for performance and features 3 to the detriment of stability, and it's 2 phenomenally buggy. Given that it's the 1 JMS fabric for Geronimo, I worry.
IBM WebSphere MQ 5 and 6 Active MQ 5.2.0
Also 3 Check out Micro QueueManager at http://codingjunky.com/page5/page4/page4.html It is 2 small, easy to install and use for smaller 1 projects.
We are using SonicMQ, JBossMQ and the "micro 18 broker" of Lotus Expeditor Integrator. We 17 are using them for different purposes:
-JBossMQ 16 is used internally and to communicate out 15 of all our Java EE applications which run 14 on JBoss. -Lotus Expeditor is used in "remote 13 sites" where we do only have limited resources 12 and IT staff -SonicMQ is our Messaging backbone, we 11 use it for connecting central systems, but 10 also to connect remote systems in approx. 1000 9 sites.
We are having good experiences with 8 all of them, but our experience is also 7 that with a more complex environment you 6 have to do a more active administration 5 of the Messaging system. This became especially 4 true with SonicMQ at our site :-) . From 3 a performance perspective we made the best 2 experiences with SonicMQ especially in Queue 1 based persistent messaging.
I have used ActiveMQ in production for a 4 couple of years but I was never happy about 3 its stability (specially with it clustered-enabled). Never 2 looked back after switching to OpenMQ. You 1 might want to look into RabbitMQ or ZeroMQ.
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.