Which JMS implementation do you use? [closed]

Answer 1

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

Answer 2

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.

Answer 3

TIBCO EMS. It's a commercial message service with Java/JMS, C, .net, and other bindings for it.

Answer 4

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.

Answer 5

We rely on AMQ (5.1) via the Camel framework, and there haven't been any issues. AMQ 4 was a tad more fishy.

Answer 6

WebLogic JMS provider when using WebLogic. Works great.