The ActiveMQ project has just released version 1.0 of its Apache 2.0 licenced, open source Message Broker and JMS 1.1 Provider.

Here's a quote from the announcement

You can embed ActiveMQ easily inside your application, use it as a purely in-VM messaging system with or without persistence or, with the flip of a single configuration string, switch to a distributed message bus in client/server, peer based or hub/spoke network topologies.

We support publish / subscriber as well as queue based models both persistent and reliable (non-persistent) modes as well as JMS transactions, XA and JCA support.

Since we fully implement J2EE 1.4's JCA contracts the RAR deployment unit should drop into any compliant J2EE container.

There is support for pluggable transports like in-VM, TCP, SSL, NIO, UDP, multicast, JGroups, JRMS, JXTA transports. Plus there's a REST API for web connectivity and Streamlets support for rich DHTML based messaging on web clients.

Out of the box support for Apache Axis and Spring is included for good measure.

You can grab a copy here or view the change log

For more details please see the home page

I know this might be touchy subject, but does anyone have links to recent performance benchmarks for ActiveMQ. Obviously how you use jms plays a big part in the actual performance, but some base numbers would be interesting.

Maybe there is a point I am missing, but performance in what area? I thought the point of messaging was for asynchronous processing. I also thought that if the load was t terrible for an implementation that it was easily scalable because it is asychronous. Just curious as to the question.

Maybe there is a point I am missing, but performance in what area? I thought the point of messaging was for asynchronous processing. I also thought that if the load was t terrible for an implementation that it was easily scalable because it is asychronous. Just curious as to the question.

well the obvious ones like, using transactional messaging when you don't need it. using point-to-point when multicast is more appropriate. not buffering the messages efficiently and forcing the JMS Server to do more work than it should. There's all sorts of silly development mistakes people make. Oh wait I forgot that all developers always use technology appropriately and don't abuse it.

performance is a key point. we've been spending too much time lately fine tuning all the various parameters on a wls jms environment just to get it working nicely. we're trying to hit a volume of 10k messages per hour and still aren't there. scalability is nice to have but first the boss wants you to spends months getting the most out of what you have. who wants to pay more license fees for another jms instance (i reallize this one's free), and more data center fees for more machines in the rack.

Its certainly early days in term of high performance :). There's some simple benchmark tests that you can run on your hardware / OS / JVM here..

http://activemq.codehaus.org/Benchmark+Tests

For non-durable topics on our 2-way opteron linux box we're getting 18K messages/second for 2K messages with 1 producer/consumer with producer, consumer and server in different JVMs. YMMV depending on your hardware / OS / JVM.

However currently the 1.0 version doesn't yet have the high performance transaction log (Howl) enabled, so for durable queues and durable topic our performance is not good - its only about 100/second due to the latency of doing a disc sync for every message. We should have the transaction log fully configured and enabled by default in 1.1 which should be out in a couple of weeks, so I'd hold off doing any serious persistent messaging benchmarks until then :)

James
Protique
Open Source Middleware

There's some simple benchmark tests that you can run on your hardware / OS / JVM here..

http://activemq.codehaus.org/Benchmark+Tests

For non-durable topics on our 2-way opteron linux box we're getting 18K messages/second for 2K messages with 1 producer/consumer with producer, consumer and server in different JVMs.

Incidentally I just ran the benchmark test on 2 separate 2-way opteron linux boxes, the server on one box and the producer and consumer VMs on the other and got about 14,000 messages/second for 2K messages for a single JMS Connection & Session in the producer & consumer. Though I highly recommend you try the benchmark out on your hardware/OS/VM.

James
Protique
Open Source Middleware

There's some simple benchmark tests that you can run on your hardware / OS / JVM here..http://activemq.codehaus.org/Benchmark+TestsFor non-durable topics on our 2-way opteron linux box we're getting 18K messages/second for 2K messages with 1 producer/consumer with producer, consumer and server in different JVMs.

Incidentally I just ran the benchmark test on 2 separate 2-way opteron linux boxes, the server on one box and the producer and consumer VMs on the other and got about 14,000 messages/second for 2K messages for a single JMS Connection & Session in the producer & consumer. Though I highly recommend you try the benchmark out on your hardware/OS/VM.JamesProtique Open Source Middleware

thanks for posting the results. that's a good baseline and definitely better than some commercial Messaging server (including non JMS messaging servers) on the market.

There's some simple benchmark tests that you can run on your hardware / OS / JVM here..http://activemq.codehaus.org/Benchmark+TestsFor non-durable topics on our 2-way opteron linux box we're getting 18K messages/second for 2K messages with 1 producer/consumer with producer, consumer and server in different JVMs.

Incidentally I just ran the benchmark test on 2 separate 2-way opteron linux boxes, the server on one box and the producer and consumer VMs on the other and got about 14,000 messages/second for 2K messages for a single JMS Connection & Session in the producer & consumer. Though I highly recommend you try the benchmark out on your hardware/OS/VM.JamesProtique Open Source Middleware

thanks for posting the results. that's a good baseline and definitely better than some commercial Messaging server (including non JMS messaging servers) on the market.

No worries. Actually it turns out one of our opteron boxes is a little flaky; if we switch the test around and run the server on the other 2-way opteron (2.2 Ghz), and have a producer and consumer on the other box in separate VMs we get about 21-22,000 messages/second for 2K message size very consistently. This is using Sun's Java 5 VM which seems to work pretty nicely on 64 bit linux

I'm sure we can get faster though, we've barely started tuning stuff.

James
Protique
Open Source Middleware

Hi,
    Wow! This sure sounds like some great software. I was wondering if you had any LATENCY numbers - specifically using the JGROUP (no server hop) transport protocol on Linux machines? My company is most interested in latency as well as throughput.
Thanks for your help!

Lil

Hi,
    Wow! This sure sounds like some great software. I was wondering if you had any LATENCY numbers - specifically using the JGROUP (no server hop) transport protocol on Linux machines? My company is most interested in latency as well as throughput.
Thanks for your help!

Lil

Hi,    Wow! This sure sounds like some great software. I was wondering if you had any LATENCY numbers - specifically using the JGROUP (no server hop) transport protocol on Linux machines? My company is most interested in latency as well as throughput. Thanks for your help!Lil

I'm afraid we've not done any latency tests yet. Since ActiveMQ is very SEDA style there is a fair bit of asynchronous processing and so there will be a small latency cost under heavy load. Though latency does seem fairly low (from a completely non-scientific perception) - e.g. when you stop a producer, it takes a very short amount of time for the consumer to catch up & finish processing its messages.

For 1.1 we should have high performance non-durable queues implemented so I'll create a benchmark for RPC round trip testing.

James
Protique
Open Source Middleware

Ahhh, SEDA. That would explain the excellent baseline performance numbers you posted. Looking at some old JMS benchmarks on Xeon hardware by some of the well known vendors, some of them max out around 15K messages/second. Maybe it's time for the vendors to run a new set of benchmarks using dual Opteron boxes :)

Ahhh, SEDA. That would explain the excellent baseline performance numbers you posted. Looking at some old JMS benchmarks on Xeon hardware by some of the well known vendors, some of them max out around 15K messages/second. Maybe it's time for the vendors to run a new set of benchmarks using dual Opteron boxes :)

Agreed. Though maybe they should wait a bit until we've tuned ActiveMQ some more :)

I've gotta say, I'm very impressed with these dual Opteron boxes. £3K a piece and they're very fast - I've been really trying to max them out in CPU usage and failing miserably so far :)

James
Protique
Enteprise Open Source Solutions

I compiled a list of open source JMS projects:

  http://wiki.java.net/bin/view/Javapedia/JMS

I compiled a list of open source JMS projects:  http://wiki.java.net/bin/view/Javapedia/JMS

Well, looks like imlementing JMS as as fun as writing another-web-ui-framwork.

Does ActiveMQ support clustering? Can we have clustered/distributed Queues?


alireza

Does ActiveMQ support clustering?

Yes. We use ActiveMQ to implement ActiveCluster which is a cluster communication abstraction, for creating distributed protocols like discovery, master/slave, distributed locking & cluster coordination etc. We plan to use ActiveCluster to create a self-discoverying cluster of ActiveMQ clients & brokers which can automatically arrange themselves into master & slaves for HA etc.

 Can we have clustered/distributed Queues?alireza

Here's how distributed queues work, though 1.0 has fairly limited support for distributed networks of brokers; this will be resolved fully in 1.1 in a couple of weeks.

We don't currently support clustered persistence in ActiveMQ - we plan on implementing a fully clustered master/slave style distributed transaction log to provide high availability of message persistence. Until we implement that you can use either a clustered JDBC database or use a SAN / shared file system to achieve the same effect.

When we port the native Berkeley DB code to catch up with the pure Java Berkeley DB code we use (again in 1.1), you could also use Berkeley DB High Availability to achieve clustered persistense.

James
Protique
Open Source Middleware

... because James Strachan used to work for a major commercial JMS implementation vendor, and knows what he is doing!

There's a tendency to knock 'Yet Another X' projects, and I understand people getting jaded (see some of the reactions to Wicket, Groovy, Pico, even Geronimo), but please at least check the project out before groaning (or biling)!

There is always room for projects that learn from past mistakes, have cleaner implementations and offer greater variety to developers.

(OK, James, you owe me a drink! =0)

I've been using it to build a JMS framework, and ActiveMQ is excellent for embedded use and Junit testing of JMS code. It's configured by Spring, and ActiveMQ's all Javabean implementation of JMS 1.1 makes this very easy. Plus, the mailing list was very helpful in helping me get this working and sweep the cobwebs off my dusty JMS programming experience :-)

I've been using it to build a JMS framework, and ActiveMQ is excellent for embedded use and Junit testing of JMS code. It's configured by Spring, and ActiveMQ's all Javabean implementation of JMS 1.1 makes this very easy. Plus, the mailing list was very helpful in helping me get this working and sweep the cobwebs off my dusty JMS programming experience :-)

that should have been to test a JMS framework... I don't have to directly use ActiveMQ classes directly because it's features are available through the JMS 1.1 interfaces and Spring's flexible configuration allow me to decouple my code from the JMS implementation.... Now if I could just find a complete JMS 1.0.2 opensource implementation that I can embed for unit tests...

I've been using it to build a JMS framework, and ActiveMQ is excellent for embedded use and Junit testing of JMS code. It's configured by Spring, and ActiveMQ's all Javabean implementation of JMS 1.1 makes this very easy. Plus, the mailing list was very helpful in helping me get this working and sweep the cobwebs off my dusty JMS programming experience :-)

that should have been to test a JMS framework... I don't have to directly use ActiveMQ classes directly because it's features are available through the JMS 1.1 interfaces and Spring's flexible configuration allow me to decouple my code from the JMS implementation.... Now if I could just find a complete JMS 1.0.2 opensource implementation that I can embed for unit tests...

JMS 1.1 is a superset of 1.0.2b. So can't you just use ActiveMQ when you need either a 1.1 or 1.0.2b provider?

James
Protique
Open Source Middleware

JMS 1.1 is a superset of 1.0.2b. So can't you just use ActiveMQ when you need either a 1.1 or 1.0.2b provider?JamesProtiqueOpen Source Middleware

Because I want to make sure I'm not accidentally using any 1.1 API calls... and because I get this:

org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'connectionFactory' defined in class path resource [activemq.xml]: Class that bean class [org.codehaus.activemq.ActiveMQConnectionFactory] depends on not found; nested exception is java.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Stats
java.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Stats

JMS 1.1 is a superset of 1.0.2b. So can't you just use ActiveMQ when you need either a 1.1 or 1.0.2b provider?JamesProtiqueOpen Source Middleware

Because I want to make sure I'm not accidentally using any 1.1 API calls... and because I get this:org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'connectionFactory' defined in class path resource [activemq.xml]: Class that bean class [org.codehaus.activemq.ActiveMQConnectionFactory] depends on not found; nested exception is java.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Statsjava.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Stats

To check that you're not using any JMS 1.1 features you could just compile your code against the JMS 1.0.2b jar - you don't need to switch JMS providers.

The class dependency is on the J2EE management statistics which we implement. These are a separate jar (e.g. geronimo-spec-j2ee-management.jar) and has nothing to do with JMS 1.1 v JMS 1.0.2b. So you could still use ActiveMQ as your JMS 1.0.2b provider and you're 1.1 provider.

James
Protique
Open Source Middleware