We are using ActiveMQ 5.2 as our implementation of choice and we picked it a while ago. It performs well enough for our use right now. Since its been a while, I was wondering what other Java Message Service implementations are in use and why? Surely there are more than a few.
Which JMS implementation do you use? [closed]
Before delving into JMS, consider AMQP as well - might be a new standard. JMS providers I worked with (in varying degrees):
TIBCO EMS - very quick and robust, good API support, Java friendly, native C API exists. Best commercial choice I've used.
Websphere MQ (and its JMS implementation) - so, so. Pub/sub not exactly quick, many configurations options and choices are 'strange' and overly complex from the long history of that product. Just look at the amount of documentation...
Solace JMS - very high throughput (the JMS broker is built in hardware !), good choices of connecting protocols (MQTT, AMQP, XML over http as admin protocols)
Fiorano MQ - used to be agressive in marketing but lost a lot of market share, maturity concerns
Sonic MQ - solid product, also supports a C API
Active MQ - if you want to go with an open-source product (unexpensive support, great community, limited add-on products, limited enterprise features) this is probably your best choice. Works out of the box and is the backbone of several tools like Apache Camel, for example.
What's the difference between solace jms and tibco ems? The reason i ask, we are running tibco ems on solace hw, but it's tibco ems broker. I guess solace jms is completely diff beast? –
Begun
Are you sure you are running EMS on a Solace hardware ? That would be a strange combination. TIBCO EMS is software only (there's another hardware version of it) and Solace is hardware by default (they also have a software VM for testing). And yes, Solace JMS and TIBCO JMS (=EMS) are different - different companies, but both support the same API (JMS) –
Straw
Yup... I've seen this setup in several places. They buy the messaging infra (hw) from Solace and they run tibco over it... For all the java apps they use tibco libraries and for anything really low latency they write C++ that uses the solace system level stuff... I think you're talking about the latter. If broker is built in hw, you need to go low level to interact with it, makes sense. –
Begun
Interesting - why wouldn't they use Solace Java API ? Solace to EMS traffic won't work easily together. I thought the grand idea is that every app can talk to every app. Well... –
Straw
I think this covers the gist of it solace.com/press-releases/… –
Begun
We rely on AMQ (5.1) via the Camel framework, and there haven't been any issues. AMQ 4 was a tad more fishy.
WebLogic JMS provider when using WebLogic. Works great.
Thanks. Is this still valid now ? We need to implement a queue in a weblogic environment. I am thinking if I should choose ActiveMQ or internal Weblogic JMS ? –
Cacology
Already outdated, but please consider one major downside of WebLogic: Whenever you want to communicate with clients outside the Weblogic environment (external producer/consumer), their Java Version must match the weblogic one! So any java version upgrades are difficult or impossible! ActiveMQ (or RabbitMQ) are not limited to the java version (or even to java, because you can build clients in any language). –
Vacuity
TIBCO EMS. It's a commercial message service with Java/JMS, C, .net, and other bindings for it.
Sun's Open source OpenMQ (https://mq.dev.java.net/). You can get free and paid support for the same.
See this blog post about some comparison with ActiveMQ, etc -- http://alexismp.wordpress.com/2008/06/06/openmq-the-untold-story/.
I've heard that OpenMQ is more stable.
ActiveMQ is more flexible. as in, you can use it with more languages. There are probably more people on ActiveMQ's mailing list than OpenMQ.
In one of the recent projects I was in we used Sonic MQ. Good overall implementation with good bindings to .NET.
We had a little of scalability problems, but I have to admit that the scalability requirements were very strict: if I can recall correctly, something like 20,000 messes a second with no delays allowed between the 200 different clients (every client had to receive every message at the same time).
Is there any implementation that can scale so high? –
Climate
@Mani: I don't have the details about the exact configuration or architecture the queuing system that was put in place because I wasn't part of the middleware dev team, but yes, we ended up reaching those levels of throughput with Sonic MQ. It took several iterations trying different hardware and queue configuration schemes though. –
Mangonel
I've used JBossMQ, which comes with JBoss app server up to version 4, and which is solid but limited. JBoss Messaging was the replacement, comes with JBossAS 5, and is a huge improvement.
ActiveMQ I have a real dislike for. The developer(s) seem to have gone for performance and features to the detriment of stability, and it's phenomenally buggy. Given that it's the JMS fabric for Geronimo, I worry.
Our experience was that version 3 and 5 are significantly better than 4 for ActiveMQ. –
Cheerly
...in terms of bugginess, I meant to type. –
Cheerly
I tried 5.1 when it came out, and found that the Spring integration was broken in very simple and obvious ways, whereas 5.0 worked fine in that respect. I have no confidence in the testing regime of ActiveMQ any more. –
Tuckerbag
IBM WebSphere MQ 5 and 6 Active MQ 5.2.0
Also Check out Micro QueueManager at http://codingjunky.com/page5/page4/page4.html It is small, easy to install and use for smaller projects.
We are using SonicMQ, JBossMQ and the "micro broker" of Lotus Expeditor Integrator. We are using them for different purposes:
-JBossMQ is used internally and to communicate out of all our Java EE applications which run on JBoss. -Lotus Expeditor is used in "remote sites" where we do only have limited resources and IT staff -SonicMQ is our Messaging backbone, we use it for connecting central systems, but also to connect remote systems in approx. 1000 sites.
We are having good experiences with all of them, but our experience is also that with a more complex environment you have to do a more active administration of the Messaging system. This became especially true with SonicMQ at our site :-) . From a performance perspective we made the best experiences with SonicMQ especially in Queue based persistent messaging.
I have used ActiveMQ in production for a couple of years but I was never happy about its stability (specially with it clustered-enabled). Never looked back after switching to OpenMQ. You might want to look into RabbitMQ or ZeroMQ.
© 2022 - 2024 — McMap. All rights reserved.