By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Jeff Genender is CTO and chief architect at Savoir Technologies Inc., a consulting, training and support company offering open source solutions. An open source evangelist, he has over 20 years of software architecture, team lead and development experience in multiple industries. He will be delivered the Architecture track keynote at the Java Symposium in March 2011, where he discussed ActiveMQ.
For those who aren’t that familiar with ActiveMQ, what might be surprising?
Jeff Genender: Its capabilities. Its ability to scale both horizontally and vertically; [its ability to] work with network clusters. That it’s one of the fastest JMS containers out there. It’s one of most popular JMS containers out there, and one reason is it’s free. We run into a lot of companies migrating from some of the bigger [commercial] JMS implementations, not only because of its capabilities, but because it has many things that are different [and go] above and beyond what a normal JMS implementation can do, and with speed. The fact that it’s open source and better than many commercial implementations people will find fascinating.
What are the most typical problems with ActiveMQ that you’ll be addressing in your presentation at TheServerSide Java Symposium?
Genender: The most common is the container appears to seize up and you need to restart. People try to tweak the memory and JVM parameters, but that usually won’t fix it. That’s one of the biggest areas – people don’t think ActiveMQ is stable and they’ll have to reboot it. The same thing with queues, why do you get a stuck queue and you can’t write to it anymore? We’ll talk about how to fix that. Seizing has to do with tuning parameters. We’ll talk about how to set up ActiveMQ and memory configurations within the MQ configuration files.
The other common problem is architecture, so they’ll be some points on how to properly utilize ActiveMQ. You don’t’ want to use it as a message store, when it’s really an event engine, so [we’ll address] how to properly set up producers and consumers so you’ve got a proper flow going through systems. There are some architectural things people need to think about in going through the development process.
How many of the problems are architectural vs. tuning problems?
Genender: About 25% are architectural problems. That seems to be a bigger issue because it has to do with how fast producers are producing and consumers are consuming, and whether you’re using pooling or not. You run into those a lot, usually after the architecture is done, and tuning doesn’t fix it if it’s an architecture problem. These are hot points for folks. They’ve built this system, produced this design and are in production, and now they’re being told they have to change the architecture. We’ll talk about running into these items and what they can do to mitigate this.
The problem is not knowing the container completely or understanding what JMS is all about. A lot of folks will use it as a message store or like a database as opposed to an event engine. That’s one of the biggest areas. You don’t want to park your message here. We’ll point to an example architecture to mitigate that issue.
Do you have an implementation tip you will be discussing, particularly for high load systems?
Genender: For scalability, utilize network brokers - and master-slave failover for high availability. Most of our clients in production will use both a network of brokers for high load, and almost always use master-slave for high availability.
What will the takeaway of your talk be?
Genender: To walk out and be able to implement ActiveMQ with a high degree of confidence that it will scale and perform well, and be able to debug and figure out what’s going on with their own stacks without calling in the experts.
This is part one of a two-part interview with Jeff Genender. In part two, he talks about SOA infrastructure, and ESBs in particular.