-
How to tune Apache ActiveMQ (18 messages)
- Posted by: Joseph Ottinger
- Posted on: June 15 2006 10:59 EDT
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.Threaded Messages (18)
- Apache Incubator by Guillaume Nodet on June 15 2006 12:31 EDT
- Apache Way by Jon Kofal on June 15 2006 17:21 EDT
- Re: Apache Way by Yanick Duchesne on June 15 2006 09:27 EDT
- Apache Way by Jon Kofal on June 15 2006 17:21 EDT
- Re: How to tune Apache ActiveMQ by Erik Onnen on June 15 2006 23:20 EDT
- Re: How to tune Apache ActiveMQ by James Strachan on June 16 2006 06:03 EDT
- ... and why not write your own VM and OS while you are at it... by Tatu Saloranta on June 16 2006 15:12 EDT
- The larger picture by Ed Peters on June 19 2006 08:50 EDT
- How to tune solutions for Business Process Integration ... by Roland Altenhoven on June 17 2006 04:05 EDT
- Any tutorial on Tomcat/ActiveMQ? by Yakov Fain on June 18 2006 07:48 EDT
- Re: Any tutorial on Tomcat/ActiveMQ? by Roland Altenhoven on June 19 2006 00:38 EDT
-
Not bits and pieces by Yakov Fain on June 19 2006 09:37 EDT
-
Re: Not bits and pieces by James Strachan on June 19 2006 12:55 EDT
-
Re: Not bits and pieces by Yakov Fain on June 20 2006 06:44 EDT
-
Re: Not bits and pieces by James Strachan on June 20 2006 06:57 EDT
-
Re: Not bits and pieces by Roland Altenhoven on June 20 2006 09:01 EDT
-
Re: Not bits and pieces by James Strachan on June 20 2006 10:53 EDT
- Re: Not bits and pieces by Roland Altenhoven on June 21 2006 01:32 EDT
-
Re: Not bits and pieces by James Strachan on June 20 2006 10:53 EDT
-
Re: Not bits and pieces by Roland Altenhoven on June 20 2006 09:01 EDT
-
Re: Not bits and pieces by James Strachan on June 20 2006 06:57 EDT
-
Re: Not bits and pieces by Yakov Fain on June 20 2006 06:44 EDT
- Re: Not bits and pieces by Roland Altenhoven on June 19 2006 03:01 EDT
-
Re: Not bits and pieces by James Strachan on June 19 2006 12:55 EDT
-
Not bits and pieces by Yakov Fain on June 19 2006 09:37 EDT
- Re: Any tutorial on Tomcat/ActiveMQ? by Roland Altenhoven on June 19 2006 00:38 EDT
-
Apache Incubator[ Go to top ]
- Posted by: Guillaume Nodet
- Posted on: June 15 2006 12:31 EDT
- in response to Joseph Ottinger
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. -
Apache Way[ Go to top ]
- Posted by: Jon Kofal
- Posted on: June 15 2006 17:21 EDT
- in response to Guillaume Nodet
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. -
Re: Apache Way[ Go to top ]
- Posted by: Yanick Duchesne
- Posted on: June 15 2006 21:27 EDT
- in response to Jon Kofal
Drop-in replacement... "SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging" http://www.slf4j.org/ -
Re: How to tune Apache ActiveMQ[ Go to top ]
- Posted by: Erik Onnen
- Posted on: June 15 2006 23:20 EDT
- in response to Joseph Ottinger
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? -
Re: How to tune Apache ActiveMQ[ Go to top ]
- Posted by: James Strachan
- Posted on: June 16 2006 06:03 EDT
- in response to Erik Onnen
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?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 -
... and why not write your own VM and OS while you are at it...[ Go to top ]
- Posted by: Tatu Saloranta
- Posted on: June 16 2006 15:12 EDT
- in response to Erik Onnen
... 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. -
The larger picture[ Go to top ]
- Posted by: Ed Peters
- Posted on: June 19 2006 08:50 EDT
- in response to Erik Onnen
(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". -
How to tune solutions for Business Process Integration ...[ Go to top ]
- Posted by: Roland Altenhoven
- Posted on: June 17 2006 04:05 EDT
- in response to Joseph Ottinger
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 -
Any tutorial on Tomcat/ActiveMQ?[ Go to top ]
- Posted by: Yakov Fain
- Posted on: June 18 2006 07:48 EDT
- in response to Joseph Ottinger
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 -
Re: Any tutorial on Tomcat/ActiveMQ?[ Go to top ]
- Posted by: Roland Altenhoven
- Posted on: June 19 2006 00:38 EDT
- in response to 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 -
Not bits and pieces[ Go to top ]
- Posted by: Yakov Fain
- Posted on: June 19 2006 09:37 EDT
- in response to Roland Altenhoven
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. -
Re: Not bits and pieces[ Go to top ]
- Posted by: James Strachan
- Posted on: June 19 2006 12:55 EDT
- in response to Yakov Fain
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.
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
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. -
Re: Not bits and pieces[ Go to top ]
- Posted by: Yakov Fain
- Posted on: June 20 2006 06:44 EDT
- in response to James Strachan
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 -
Re: Not bits and pieces[ Go to top ]
- Posted by: James Strachan
- Posted on: June 20 2006 06:57 EDT
- in response to Yakov Fain
James,
Totally agreed :) The performance tuning guide was the first of hopefully many articles and best practice guides. James LogicBlaze Fuse: Open Source SOA
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 -
Re: Not bits and pieces[ Go to top ]
- Posted by: Roland Altenhoven
- Posted on: June 20 2006 09:01 EDT
- in response to James Strachan
The performance tuning guide was the first of hopefully many articles and best practice guides.
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
James
LogicBlaze
Fuse: Open Source SOA -
Re: Not bits and pieces[ Go to top ]
- Posted by: James Strachan
- Posted on: June 20 2006 10:53 EDT
- in response to Roland Altenhoven
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 SOAThe 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 -
Re: Not bits and pieces[ Go to top ]
- Posted by: Roland Altenhoven
- Posted on: June 21 2006 01:32 EDT
- in response to James Strachan
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.deThe 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 -
Re: Not bits and pieces[ Go to top ]
- Posted by: Roland Altenhoven
- Posted on: June 19 2006 15:01 EDT
- in response to Yakov Fain
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.