LogicBlaze has published "How to tune Apache ActiveMQ," a document discussing factors that make ActiveMQ go faster (or give it other characteristics). It's a good idea, one that other products could use. The tips include choosing the right Quality of Service, tuning the streaming, avoiding message copying and unnecessary serialization, and others. Oddly enough, ActiveMQ is still in the Apache incubator process, despite being fairly mature.

Oddly enough, ActiveMQ is still in the Apache incubator process, despite being fairly mature.

The Apache Incubator (see http://incubator.apache.org/) primary purpose is to clear IP issues and to ensure the community is healthy and behave the "Apache Way", not about code maturity and quality.

The Apache Incubator... primary purpose is to clear IP issues and to ensure the community is healthy and behave the "Apache Way"

Must-Use-Commons-Logging I couldn't resist that one, sorry.

Drop-in replacement... "SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging" http://www.slf4j.org/

I'd be curious to know if users consider these 'real' options relative to how they use JMS. I've used JMS for some time now and never in a situation where duplicate delivery was acceptable let alone any sort of potential message loss as is possible with async sends or without transactions. I guess what I'm asking is, if you don't care about the ACID-ness of JMS, why not just use IP multicast and bypass the message broker all together? I'm not interested in "JMS gives you a consistent API" type answers or "multicast is sockets and therefore to hard" both of which can be hidden behind a simple abstraction layer allowing JMS or multicast. If you're interested in such optimizations, why not optimize it to the hilt and bypass JMS completely?

I'd be curious to know if users consider these 'real' options relative to how they use JMS

Thanks for the vote of confidence :). One of the first recommendations is to boost performance using JMS transactions and to batch more operations within a transaction to increase throughput. Pretty standard tuning advice to working with most transactional resources like JDBC or JMS. Most certainly 'real'.

I've used JMS for some time now and never in a situation where duplicate delivery was acceptable let alone any sort of potential message loss as is possible with async sends or without transactions.

Thats fine then, don't use those options :) One of the things which makes messaging and SOA in general interesting is there is a massive number of different use cases, scenarios and requirements. Whether its crazy high volume RFID or market data prices or distributed caching (where a duplicate or missed message is not the end of the world; others will come along later or you can always flush a cache or do some reconcilation to deal with failures) - or whether its more traditional MQSeries type of stuff where everything is transactional, persistent and often using XA to make sure you absolutely never ever loose a message - including sometimes requiring multiple copies of the message in different data centres to insure against catastrophic hardware failure. The performance tuning guide is an attempt to discuss every possible way in which you can trade the various configuration options and quality of service constraints with performance. Clearly some of them will not apply to all use cases. Like most things in IT, there are tradeoffs depending on what you need.

I guess what I'm asking is, if you don't care about the ACID-ness of JMS, why not just use IP multicast and bypass the message broker all together?

JMS providers can sit on top of multicast too BTW :)

I'm not interested in "JMS gives you a consistent API" type answers or "multicast is sockets and therefore to hard" both of which can be hidden behind a simple abstraction layer allowing JMS or multicast. If you're interested in such optimizations, why not optimize it to the hilt and bypass JMS completely?

It depends on what you need. Certainly as we've shown you can use a high performance open source messaging system based on JMS to go very fast and support a whole range of transports, topologies and reliability characteristics. e.g. if you need 20,000 messages/second for a single producer/consumer thread its easily possible with non-persistent topics. But by all means write multicast code if thats what you'd rather do; noone's forcing you to use JMS if you have some aversion to standard APIs. James LogicBlaze Fuse: Open Source SOA

... I guess what I'm asking is, if you don't care about the ACID-ness of JMS, why not just use IP multicast and bypass the message broker all together?

There can be lots of reasons, like wanting to retain the future possibility of wanting ACID features, and the fact that multicast doesn't really work/scale nicely outside of LANs. The resulting system with an external queuing component will also be more flexible, easier to move pieces around, change topology. And finally, it is non-trivial amount of time one uses for writing messaging systems from scratch. JMS implementations save time, and good ones offer performance one can't trivially exceed with modest amount of work. So one could as well ask why on earth would you want to write your own, unless you have a very specific need? Even if you just got a typical multicast implementation with typical characteristics, you have probably saved lots of time.

(Sorry in advance if my response isn't snippy enough.) Even if out-of-order, duplicate, and nonguaranteed delivery aren't your cup of tea, you can still take advantage of messaging optimizations like this if your app has enough persistent state. You would write your own error detection/correction logic, which is still probably going to involve less code than writing a custom messaging implementation. So in essence you're telling the JMS provider, "just go fast, and I'll pick up the pieces".

In my personal experience is Apache ActiveMQ a good and stable solution which provides high performance messaging and is darkly integrated in ServiceMix - one of the ESB Solutions from Apache with functionally support for the JBI-Standard (Java Business Integration ). I think too: The performance criterions are a very important case in the areas of SOA and Enterprise Messaging. Some people has experienced, that a few of products destinated to Business Process Integration areas (... maybe with prices located in the higher regions...), has sometimes a little bit of trouble, to provide the necessary performance when the message interchange is based on high traffic and high volume. Good, maybe this problem can be solved with some tuning measures (when the generic product structure allows this way...), extented hardware-solutions, clustering or some other special tricks - but in some cases this measures are unfortunately not satisfactory and maybe, so this products are not usable in this destinated projects. Finally, i think that products which provides - among the other important things - basically a high performance based structure and permits furthermore extended tuning capabilities, are principally the right solution for the difficult missions in the SOA and Enterprise Messaging areas. Roland --- SOA Kompetenznetzwerk Information & Collaboration-Portal for SOA & ESA in German Language http://soa-competence-network.de http://esa-competence-network.de

Before even trying to fine tune ActiveMQ, I guess, one would need to configure Tomcat with Active MQ :) I wonder if anyone can point me to a step-by-step tutorial showing how to configure a Tomcat Web Server with Active MQ . Google returns bits and pieces of the relevant info... I've heard that ActiveMQ may be the best open source messaging solution, and using it with a super popular Tomcat Web server seems like a no-brainer to me. But where is the doc? Thanks, Yakov Fain

The following Tomcat instructions are not a step-by-step tutorial for beginners. But I think, really interesting people can found many helpful informations by a look to the extended document-site of ActiveMQ and their associated mailing-lists. http://www.activemq.com http://www.activemq.com/site/tomcat.html

I guess, this is the difference between the open source and professional products. The OS vendors assume that experienced developers will eventually figure it out, which is true if your project really depends on this software. My case is different. I'm writing a chapter for a book on integration Java with some third-party software by using messaging. Hence, I decided to take a couple of popular open source products such as ActiveMQ and Tomcat. After spending an hour unsuccessfully trying to make them talk to each other, I'm considering picking up another messaging tool for my sample application. I'm sure, if I'd spent a bit more time, I'd figure it out... But I'd rather spend my time doing something more creative than fighting with configuring queues, topics ports and jars.

I guess, this is the difference between the open source and professional products. The OS vendors assume that experienced developers will eventually figure it out, which is true if your project really depends on this software.

My case is different. I'm writing a chapter for a book on integration Java with some third-party software by using messaging. Hence, I decided to take a couple of popular open source products such as ActiveMQ and Tomcat. After spending an hour unsuccessfully trying to make them talk to each other, I'm considering picking up another messaging tool for my sample application. I'm sure, if I'd spent a bit more time, I'd figure it out... But I'd rather spend my time doing something more creative than fighting with configuring queues, topics ports and jars.

I'm sorry to hear you are having trouble - though folks have trouble using proprietary products too (believe me, I've had lots of trouble with lots of proprietary products in the past :). The way to get help with open source projects is to join the community and ask for help. e.g. try using the Apache ActiveMQ discussion forum. http://incubator.apache.org/activemq/discussion-forums.html If you are writing a book on integration with Java it might be an idea to explain to your users how to work with open source and open source communities avoid getting stuck. BTW with ActiveMQ you don't have to configure topics or queues. I can also recommend the FAQ which has lots of useful information in it. James LogicBlaze Fuse: Open Source SOA

James, Thank you for the links, which add to my collection of bits and pieces :) Open source products and commercial startups suffer the same disease: lack of "best practices" writeups. I've been attending a training on one of the very expesnive but new product. They taught us how to use their product. But what's the proper way of using this product with other product that an enterprise happened to have? The instructor was not able to answer... A hugely popular Tomcat does not have its own messaging transport. ActiveMQ is earning a good reputation as an open source MOM. You do not have to be a rocket scientist to figure out that writing a set of "best practices" articles would really help in marketing of ActiveMQ... Thank you for your response, Yakov Fain

James,

Thank you for the links, which add to my collection of bits and pieces :)

Open source products and commercial startups suffer the same disease: lack of "best practices" writeups. I've been attending a training on one of the very expesnive but new product. They taught us how to use their product. But what's the proper way of using this product with other product that an enterprise happened to have? The instructor was not able to answer...

A hugely popular Tomcat does not have its own messaging transport. ActiveMQ is earning a good reputation as an open source MOM. You do not have to be a rocket scientist to figure out that writing a set of "best practices" articles would really help in marketing of ActiveMQ...

Thank you for your response,
Yakov Fain

Totally agreed :) The performance tuning guide was the first of hopefully many articles and best practice guides. James LogicBlaze Fuse: Open Source SOA

The performance tuning guide was the first of hopefully many articles and best practice guides.

James
LogicBlaze
Fuse: Open Source SOA

Please can I ask, which particular themes are actually planned ? Existing such plans for ServiceMix too ? Roland SOA Kompetenznetzwerk http://www.soa-competence-network.de

The performance tuning guide was the first of hopefully many articles and best practice guides.

James
LogicBlaze
Fuse: Open Source SOA

Please can I ask, which particular themes are actually planned ?

Existing such plans for ServiceMix too ?

Roland
SOA Kompetenznetzwerk
http://www.soa-competence-network.de

We are in the planning stage now; we're hoping to distill down various best practices and content from our training courses and customer engagementts on using Fuse, ActiveMQ and ServiceMix into some more guides on the LogicBlaze DevZone. James LogicBlaze Fuse: Open Source SOA

James, many thanks for your informations. All interested people to be well up in the great engagement from LogicBlaze and their professional team by many of the known Open Source Solutions. I think that the numerous people from the Open Source Community and surely many Corporate Users of ActiveMQ and ServiceMix, are gladly to make available in such way their own experiences too, which can be very helpful to provide together a large number of this mentioned, magnificent extensions. Nice days "y mucho Suerte" by the TSS-Conference beginning today in Barcelona. Roland SOA & ESA Kompetenznetzwerk http://www.soa-competence-network.de http://www.esa-competence-network.de

The performance tuning guide was the first of hopefully many articles and best practice guides.

James
LogicBlaze
Fuse: Open Source SOA

Please can I ask, which particular themes are actually planned ?

Existing such plans for ServiceMix too ?

Roland
SOA Kompetenznetzwerk
http://www.soa-competence-network.de

We are in the planning stage now; we're hoping to distill down various best practices and content from our training courses and customer engagementts on using Fuse, ActiveMQ and ServiceMix into some more guides on the LogicBlaze DevZone.

James
LogicBlaze
Fuse: Open Source SOA

On First, I think many Open Source Solutions are more "professional products" in the areas functionally, quality, documentation and support - as some others, provided by business manufacturer. On Second: Each people working professionally in IT-Areas, knows that existing good business based products and bad business based products - sometimes you receives good documentation and business-support and sometimes you receives bad documentation and business-support for your problems - in some cases none of this. How good is the documentation for the detailled configurations of "Business based Products" and Developments in Integration Areas really? How great is the time exposure to learn Business Products, to know their configurations and the development for this solutions ? Existing really great differences between Business based Products and Open Source Solutions by this criterions ? What is the reason, because today are so many "Business Products" based basically on Open Source Technologies ? What is the reason, because today so many professional projects are based basically on Open Source Technologies ?

I guess, this is the difference between the open source and professional products. The OS vendors assume that experienced developers will eventually figure it out, which is true if your project really depends on this software.

My case is different. I'm writing a chapter for a book on integration Java with some third-party software by using messaging. Hence, I decided to take a couple of popular open source products such as ActiveMQ and Tomcat. After spending an hour unsuccessfully trying to make them talk to each other, I'm considering picking up another messaging tool for my sample application. I'm sure, if I'd spent a bit more time, I'd figure it out... But I'd rather spend my time doing something more creative than fighting with configuring queues, topics ports and jars.