Slashdot Mirror
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?"
These are kind of obvious, but it might be useful to take a look at JBossMQ in JBoss, and at OpenJMS.
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I have tried SwiftMQ, 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 or Elvin. The OpenJMS and JBossMQ are okay, but still lag behind the commercial vendors, but are quickly catching up.
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
I'm an admin for a small consulting company where all my co-workers are j2ee folks, they all love tibco.
never underestimate the bandwidth of a station wagon full of tapes
This is probably more than a bit offtopic, but developerworks has an article on writing vendor independant JMS code. It's availible here.
Unfortunetly I've never really dealt with JMS, so I can't really answer the question in the post.
ok... this is all heresay until i see someone put up some hard evidence of a JMS scaling problem.
any takers?
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
it's not correct to put a "c" after "$0.02". It's like combining meters and cm in the same statement: 2 meters 12 cm is typically notated as 2.12m, not 2m.12cm.
"$0.02" or "2c" would be the correct way, but not combined.
(in addition, i see people using "0.02c", which is also incorrect, as it means 2 one hundreths of a penny, or $0.0002)
None of which have anything to do with JMS...
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.
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.
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.
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
m 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.
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.ht
Nice implementation and some sound research behind it.
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.