Mule MQ: Yet Another JMS Server?
Puneet Gupta
January 20th, 2010
MuleSoft just announced availability of Mule MQ.
Seriously! Do we really need another messaging server in this already crowded market? Then again, do we really need Google Nexus One and Motorola Droid when Apple’s iPhone supposedly already has almost everything one could ask for? The answer lies in the user’s need for reliability, performance, interoperability, and ease of use – in short, the answer is YES.
Reliability
The iPhone has great features, but it is a network hog resulting in dropped calls on AT&T. Similarly, there are a ton of JMS vendors with all the bells and whistles but very few who can guarantee message delivery. This problem gets worse when you try to cluster the different servers for high availability. Most JMS providers suffer from lost messages, as the message is not reliably replicated across all nodes in a cluster. Some use UDP, resulting in unnecessary network chatter–in other words, clogging network bandwidth.
Mule MQ, on the other hand, is built for reliability. It has the most advanced clustering solution, allowing users to configure the servers in a high-availability cluster and distribute clients across different nodes in the cluster. Mule MQ guarantees message delivery even if a disaster strikes.
Performance
The iPhone is pretty nifty, but have you tried opening a large email or one that has many people in the to/cc list? Have you tried running multiple apps? Enough said. Most JMS servers perform fine under normal load, but very few scale and perform under heavy load, and some just crash or hang (I can do this at will with some servers).
Mule MQ is the fastest JMS server on the planet. It can scale to thousands of clients and still perform with high throughput and low latency. It is proven and used by large banks for forex trading (thousands of clients and millions of forex quotes).
Ease of Use
Have you ever tried getting your iPhone serviced (like replacing the battery or adding more storage)? Similarly most JMS vendors have either no support or charge you through the nose for it.
Mule MQ comes with an easy-to-use administration console that allows some basic tasks like configuring security, creating queues, monitoring throughput and queue depths, etc. It also has some very advanced functionality like browsing a queue for messages and republishing an existing message from within the admin console. You no longer have to write Java clients to trace messages and debug your app. All of this comes with the same level support as the #1 open-source ESB, Mule ESB. Moreover there is out of the box integration between Mule MQ and Mule ESB. You do not have to bet your messaging infrastructure on the mercy of users on an open-source project forum.
Browse Queue’s and Resubmit Messages
Monitor Server and Message Rate
Interoperability
Ever wonder why the iPhone doesn’t support a standard USB connector? It’s simple: so that Apple can charge you $20 for a “Dock Connector to USB Cable”. Really? $20 for a USB cable? Let’s not even get started with the app store–why can’t I used Skype and Google voice to make calls? Similarly, most vendors claim to support the full JMS spec, but rarely does a client written for one vendor work for another (believe me: we know what we had to do to make our JMS connector work with all the different vendors).
Mule MQ not only supports the JMS spec but in the future also support C#, .NET, C++, Excel VBA, and other programming languages like JavaScript, Adobe Flex, Microsoft Silverlight, iPhone, Android, and J2ME. Finally all your enterprise apps can get on the same bus. You can be assured that your investment in Mule MQ will work with your other investments in web and mobile applications.
So yes, we do need another JMS Server as much as we need another iPhone killer. If you want reliability, performance, ease of use, and interoperability, give Mule MQ a try.
Note: While I used the iPhone reference for illustrative purpose here, I hope that even iPhone fans will download Mule MQ and take it for a spin!
Tags: messaging, performance, release
January 22nd, 2010 at 4:30 am
Hi
Congratulations on your release of MuleMQ
I am keen to understand how the performance claims made in the MuleMQ press release can be substantiated and verified independently.
For example it is claimed that persistent messaging is several times faster than ActiveMQ. But, unless the code is open source how can anyone check that MuleMQ is writing messages to disk properly? It is very common for messaging vendors to claim ‘persistence’ when this is only partly true, and this can cause problems for customers.
At RabbitMQ we try very hard to be clear and upfront about how we do persistence – it is important. So can anyone explain what MuleMQ does and doesn’t do?
Cheers
alexis richardson
RabbitMQ
January 22nd, 2010 at 9:44 am
Very informative and very funny. Looking forward to more blogs from Puneet….
January 22nd, 2010 at 12:16 pm
I absolutely agree most vendors don’t come clean on the persistence strategy. That is why we spent a considerable time testing and verifying different vendors i/o behavior before we measured any performance metrics.
In case the source code is not available, the alternate way to determine persistence is to monitor the system calls and disk usage. That way you can truly tell tell if data is being persisted to disk.
We used the sonic test harness for performance testing. We tested RabbitMQ (using openamq client) as well as SwiftMQ, FioranoMQ, ActiveMQ and WebSphere MQ.
We will be doing a Live Webinar demonstrating the performance test and the Admin features of Mule MQ.
January 28th, 2010 at 8:16 am
So is that a resell from my-Channels Nirvana JMS ?
Looks like it is http://www.my-channels.com/developers/nirvana/enterprisemanager/jndi/jmsintegration.htm
April 30th, 2010 at 4:41 am
Hi
I was trying to use Mule MQ to connect to remote server from my local clent.
It is showing an exception connection failure.Rname[0] was 127.0.0.1
How to set this to my server address .It is running perfectly at server with loopback test.
Can any body help me
Its urgent
Thanks and regards
Srinivas
May 3rd, 2010 at 7:42 am
Hi Puneet,
I have a use case where I have exisitng application which is publishing the
data feed in XML format to ESB over JMS channel. This feed is to be
massaged and sent across to different subscribers over different channels
like JMS, TCP Webservice and UDP. This was the main reason to select Mule as
the message massaging is done in XSLT Transformers and the data is sent
using multicast outbound routers to different channels.
We are using Active MQ 5.3.0 as JMS server and Mule 2.2.1 community edition.
Now the issue is since the feed comes in real time we need to write a high
performance system which supports around 1500 messages/second.
I tried doing some test with Active MQ using TestHarness as mentioned on
MuleSoft site and was able to get the performance of 6602 messages/second
both at publisher and subscribre end.
Now when I host the activemq (using embedded broker) inside mule and perform
the tests the performance dips down drastically from 6600 to 400msgs/second. I am able to send and
receive messages at the rate of about 400 messages per second only.
Please help in letting me know is there a way to write a high performance
JMS connector which can support messgaes upto 1500 msgs/sec using community
edition.
I understand that JMS and ESB has different intentions but the performance shouldnt come down around 30 times.
Can you please help me what shall i do to fix this. I will be really thankful to you.
Any help will be really appreciated.
Thanks in advance
Gaurav