What Java Message Service Implementation?

alapalaya queries: "If you had to implement a message dispatcher with soft real time requirements, which has to manage a lot of messages, and in general subject to a lot of problematic requirements (including object persistence); all implemented using a Java Message Service; what implementation would you use? In fewer words: in your opinion what is the best Java Message Service Implementation? Among the various JMS implementations I am currently using SonicMQ; but it doesn't seem to scale up in a proper way (to around several hundreds of clients generating from 10 to 200 messages/sec each). What do you know about other vendors/implementations?"

Re:What I Use

[Mark Wilkinson]

None of which have anything to do with JMS...

JBoss, OpenJMS

[LarryRiedel]

These are kind of obvious, but it might be useful to take a look at JBossMQ in JBoss [jboss.org], and at OpenJMS [exolab.org].

JMS does not meet real time requirements

[angel'o'sphere]

As far as I know ....

Message services are designed to guaranty message delievery, not to be particular fast or even "real time", what ever the timing criteria of you might be.

What about clustering? JMS implementations usualy support clustering, at least SonicMQ does so.

In a project I was, we used MQSeries(sp?) from IBM. It had to process 600k messages a day but it was good enough for us if a message was processed in a couple of minutes ...

Regards,
angel'o'sphere

Re:JMS does not meet real time requirements

[spike666]

this is correct. JMS was written to facilitate the MQSeries of the world. message queueing or store and foreward based guaranteed delivery systems are definately useful, but not necessarily what you want for Real Time Messaging. the additional overhead is enormous. IBM's MQSeries for example, while being an incredibly scalable, reliable, supportable product, tacks on a header of around 700 bytes. and if you're trying to do Real Time Messaging, and you dont need guaranteed delivery (even if it takes weeks), sure MQSeries will work, but its totally overkill.
for Real Time Messages, just open a socket. a) its cheaper in resources b) its faster c) its how a JMS provider will be doing it anyways.

true, but...

[splante]

The delivery is not meant to be real-time, but the JMS implementation should accept the messages in real-time even at volume, and the delivery shouldn't get bogged down to the point where it can never catch up.

We've used SonicMQ but not to the level of volume described. It may be that he's reached the limit of the hardware and needs to cluster or go to a bigger box. He's going to have to demo the competitors and see if any can do better on the same hardware, which is what I expect he is planning to do. He just wants to start the testing with one other folks have had good high-volume experiences with.

Other options???

[arberya]

I have tried SwiftMQ [swiftmq.com], in which the main engine is free, but add ons are at a modest cost. What I would like to see are JMS implementations on top of Spread [spread.org] or Elvin [dstc.edu.au]. The OpenJMS [exolab.org] and JBossMQ [jboss.org] are okay, but still lag behind the commercial vendors, but are quickly catching up.

Re:Other options???

[James Youngman]

Unfortunately Elvin seems to have a no-commercial-use license. Otherwise, I'd have said that it was an exciting system. I wish it met the Debian Free SOftware Guidelines - all it would have to do is be available for commercial use (see the DFSG document [debian.org]).

Try IBM MQ Series

[Arthur Dent]

We are using the IBM MQ series [ibm.com] in a large financial institution with clients publishing and subscribing from global locations.

I've found that it handles the load pretty well (just an informal test right now gives about five 10K messages/sec on a 100Mbps network).

The advantages of this solution are that you are not restricted to JMS clients. IBM MQ Series can deliver messages to non-JMS clients too. Admittedly, this is a non-issue if you are tossing Java objects around. In our case, we use it to pass XML data as queries and responses. I've generally found a near instantaneous response rate from the time the publish happens to when the subscriber is notified of a new message. Just my $0.02c

Tibco

[joescrooge]

I'm an admin for a small consulting company where all my co-workers are j2ee folks, they all love tibco.

Re:Tibco

[James Youngman]

While I also like Tibco, there are a small number of things that might put someone off it :-

1. "Reliable" messages aren't reliable - if you want actually-reliable messages you actually have to use "Tibco Certified Messaging" not "Tibco Reliable Messaging". The Marketing department strikes again.
2. If you use Certified Messaging ("CM") you then have to have a ledger file in order that not-yet-delivered messages can persist. Management of ledger file space is tricky and historically Tibco has had severe problems (e.g. crashes) with large ledger files (e.g. >> 40Mb).
3. If you accidentally create a certified relationship with a new party (e.g. by incorrectly setting the CM name of a system just once) then the ledger files belonging to anybody who ever sent it stuff will grow larger and larger (with the size problem mentioned above) unledd you break the CM relationship. To break the CM releationship, you have to ask the application to do it - and unless the app has some way of telling it to break the relationship, this is very hard (i.e. I know of no other documented way to achieve it).
4. If you have short-lived processes (&lt30s) you can't use Tibco messaging effectively without a relay agent. This is because the sender's runtime support code has to be able to re-send the message datagram for up to 30 seconds - so shorter-lived processes work much less well and will lose data in the ordinary run of things. Using a relay agent solves this but is not something you can retro-fit without changing code (e.g. you can't do it to someone else's code). On the plus side, though, it's a one-line change.
5. Tibco messaging outside the local IP subnet relies on Tibco rvrd processes - which set up a point-to-point link for a set of subjects. This can be a small pain.
6. Multicasting is fiddly to set up (there's not a lot of good documentation on the correct usage of the network parameter).
7. Although Tibco also has a distributed transaction API, it's not clear how this interacts with TIBCO RV (RV is the name for the Tibco messaging product which everyone else calls Tibco). J2EE has transaction and messaging APIs and it's not clear to me if the Tibco products in those niches integrate seamlessly (I have used Tib/RV extensively but never used the transactional control product).
8. Tibco/RV messages are completely free-form - there is no way of ensuring that all messages of a specific type ("subject" in Tibco parlance) have any given structure. Of course, this can be a benefit too - it depednds.

Please don't get the impression from the above that Tibco is not a good product. It is, and it is (can be made to be) reliable enough for most purposes. For example, significant fractions of the UK's electricity market depends on Tibco for energy trading.

Vendor Independant JMS - Offtopic?

[illusion_2K]

This is probably more than a bit offtopic, but developerworks has an article on writing vendor independant JMS code. It's availible here [ibm.com].

Unfortunetly I've never really dealt with JMS, so I can't really answer the question in the post.

HERESAY! what EVIDENCE can you really show me?

[mozkill]

ok... this is all heresay until i see someone put up some hard evidence of a JMS scaling problem.

any takers?

Re:HERESAY! what EVIDENCE can you really show me?

[mozkill]

are we talking about a centralized JMS system or a distributed system? its obvious to me that it scales just fine, especially in a distributed application, such as SOAP, for example. it just depends on the architecture beneath it. if there is a scaling problem, then its the person that coded it, because either 1. they cant code worth a shit, or 2. they used the least efficient design in a situation where there are multiple ways of doing things. show me the code that doesnt scale, and i can probably tell that person what they should have done. but anyone could do that, right?

Are you sure you have SonicMQ configured properly?

[CrazyBob]

How do you have it set up? This doesn't strike me as a particularly heavy load. Commerce One uses Sonic and you don't get much higher/more distributed Tx rates than that.

MOM

[sql*kitten]

There are three serious players in the MOM (Message Oriented Middleware, to give it its proper name) arena:

• IBM with MQSeries [ibm.com]
  
• Oracle with AQ [oracle.com]
  
• Microsoft with MSMQ [microsoft.com]
  

There may be others around, but no-one can touch these for reliability, scalability and vendor support - the three key factors for serious enterprise infrastructure. If you already have existing code written for IBM, Oracle or MS platforms, then so much the better, I believe AQ and MSMQ are pretty much bundled with the platform anyway. Still, IBM do dominate the market, their MQSeries is used by very serious people (banks, airlines, etc) and it's very mature.

Re:MOM

[dmorin]

Interesting that you don't mention Tibco? I'm not claiming to know much about it's quality, but I'm at a bank and two competing architecture groups (after recent merger) are fighting the pros and cons of MQSeries versus Tibco so I can only assume that Tibco's got something going for it otherwise the fight would have been over quickly.

Re:MOM

[sql*kitten]

Interesting that you don't mention Tibco? I'm not claiming to know much about it's quality, but I'm at a bank and two competing architecture groups (after recent merger) are fighting the pros and cons of MQSeries versus Tibco so I can only assume that Tibco's got something going for it otherwise the fight would have been over quickly.

I've done some work with Tibco stuff, TIC, eFinance, etc. Reuters deliver their equities information streams over it. I only didn't mention it because I've never seen it used outside of finance. There is also DBUS (Deutshe Bank's own proprietary MOM), which was going to be open sourced, or so the rumor was, but I haven't heard any more of it.

Nirvana

[Anonymous Coward]

Nirvana (http://www.my-channels.com/nirvana/index.html) is a fast, robust and scalable messaging implementation. my-channels have taken the benchmarking tools from the Sonic and Fiorano and consistently outperform both implementations. Assuming execution on an appropriate hardware platform your message throughput rates and client numbers are not a problem for Nirvana

Nirvana has a powerful federated name space. The name space allows you to split the client load over multiple realms ( Nirvana server instances ) creating one way or bi-directional joins between the distributed channels/topics running on different realms. The routing of data from one channel/topic to the next can be filtered using message selectors allowing you to route content by value dynamically within the name space.

Nirvana delivers pub/sub, message queues and a peer 2 peer framework, all of which can function concurrently within one or more name spaces. Nirvana directly supports sockets. SSL enabled sockets, HTTP and HTTPS, both HTTP and HTTPS traverse normal and user authenticated proxy servers. Nirvana's client API runs in a browsers JVM without any plugin technology.

Finally the licensing model (http://www.my-channels.com/products/licensing.htm l) is unique within the messaging market, it does not penalize clients for being distributed or supporting things like high availability and business contingency. The developer licenses for all my-channels products are free. Feel free to download.

Flow control and scalability

[MetalOne]

About a year ago my company chose to use JMS for a project. Our company was writing only publishers, other company's would be writing subscribers. Therefore, I was interested in how well the JMS provider handled flow control. We did not need to persist messages to disk. There is a simple test everyone should try. In the onMessage() implementation insert an infinite loop that never returns. We ended trying about 10 vendors and none of them could handle this problem. The JMS server did 1 of 2 things. Either messages were cached for the non-responding client until the server ran out of RAM and crashed or the server stopped publishing messages to all clients. The JMS specification does not indicate how such a problem should be handled. Eventually, if a client is not responding, messages to that client will have to be dropped. Messages can only be cached for so long. JMS does not have any method of generating a notification that messages are being dropped. We worked with a couple of big companies to try and resolve this problem and they were completely incompetent in dealing with customer feed back on the issue and getting the problem resolved. We finally found a company that did fix the problem for us. Fiorano readily verified the problem and quickly turned out a fix. This test is perhaps a bit extreme. However, you never know how a client will handle the onMessage function. Perhaps they run database query to insert data into a large table. This query could take hours to run. When servers stop publishing messages until onMessage() returns you are going to get big scalability problems. I also find the JMS API to be sorely lacking from a programmatic administrative view. There is no information on who is connected, how long they have been connected, how much data was sent to a subscriber, no way to examine a subscriber's subscription profile or to set a profile for a subscriber unless you are the subscriber. There is no ability to break a connection. Some of this may be available through a provider user interface, but JMS does not address this from an API.