Note to self: investigate implementing the Double Write Buffers idea in ActiveMQ. ActiveMQ keeps several indexes into the persistent messages that it’s holding and when ActiveMQ is shutdown ungracefully, we rebuild the indexes from the data logs due to them being in inconsistent state. If your queueing up millions of messages, building those indexes can take a long time.

Whoa, time flies by, and I forgot to post about the upcoming webinar that I will be co-hosting with Rob Davies on June 10th. We will be covering some messaging basics, introducing Apache ActiveMQ and Apache Camel to the audience, but most interesting I think will be the section where Rob will be covering the results that IONA has been seeing benchmarking ActiveMQ against the SpecJMS2007 test suite. I totally agree with Rob’s comment that “An independent benchmark is important, because it negates the chance to skew home groan tests to a vendor’s strengths.”

InfoQ has posted nice article on the new features in the ActiveMQ 5.1 release versus the last 4.1 release:

For all of you who ran into issues with ActiveMQ 5.0.0 when running it in anger, I highly recommend you give the just released ActiveMQ 5.1.0 a try. This release focused focused on making the broker rock solid. It resolved several bugs which only reared their heads in high load situations. Memory leaks have been squashed and performance has even improved in several areas.

Just ran into a problem where some mutlicast tests were failing on a linux box and I could not figure out why. Did a little bit of research and found out that you may need to add a route for it first. So if you have this problem try running: