Activemq Rpms

Due to SSL issues on our koji build server it seems some people can't get at the RPMs.

Anyway, here are direct links for different versions:

for 5.3.2:

http://koji.afroditi.hellasgrid.gr/packages/activemq/5.3.2/3.el5/x86_64/activemq-5.3.2-3.el5.x86_64.rpm

http://koji.afroditi.hellasgrid.gr/packages/activemq/5.3.2/3.el5/x86_64/activemq-client-5.3.2-3.el5.x86_64.rpm

for 5.4.1:

http://koji.afroditi.hellasgrid.gr/packages/activemq/5.4.1/1.el5/x86_64/activemq-5.4.1-1.el5.x86_64.rpm

http://koji.afroditi.hellasgrid.gr/packages/activemq/5.4.1/1.el5/x86_64/activemq-client-5.4.1-1.el5.x86_64.rpm

I'll work on a better  solution with a public yum repo for this in the next days.

Fudge in Python

I though Fudge was an interesting format for messaging when Kirk Wylie first mentioned it last year.  Since then C and C++ libraries have appeared alongside the original Java and .Net.  Fudge, along with being a strongly-typed, extensible, self-describing format has some nice ideas, such as taxonomies that look like a good fit for some of our messaging use-cases, such as sending GLUE records over messaging.  In GLUE, keys are long and a taxomomy would help to reduce the byte count on the wire by a lot.  Also the typed nature gives us a big advantage over LDAP, and would save on lots of type conversions.

Another interesting usage (once you have a python implementation) would be automatic translation from Django Models to Fudge messages.  This could work very well with django-celery as a custom serializer.

With some time on my hands I decided to take a crack at a Python implementation of the specification.  The specification is short, and detailed enough to work from but diving into the reference implementations is highly recommended if you have any doubts on what should be done. 

A few days work has lead to a basic implementation up and running with all basic types working (except for date types).  There still is a lot missing, including recursive Fudge messages, taxonomies, context objects, streaming interfaces and better accessors for fields in a fudge Message object.  A lot of these are the next higher level functionality on top of the basic encoding/decoding functionality.

The code is now up at github, expect changes in the next few days as I flesh out the implementation.

(Some) Java apps run faster on fewer cores...

From Paul Tyma: Mailinator(tm) Blog: How I sped up my server by a factor of 6

Odd effects of reducing #cores for the JVM to improve message throughput.

ActiveMQ Advisories and STOMP

Advisory Messages in ActiveMQ are pretty useful, but since I mostly use STOMP clients I never really knew how useful !  I was blocked by this so prompted by a mail from Gary Tully on the activemq-users list and a long weekend coming up I sat down and tried to work out just what was needed.  In the end, after a brief diversion into why JmsFrameTranslator isn't actually used in the server, I got a pretty simple implementation up and running.  This was aided by XStream already being a dependency and it having pretty good JSON support.  Some tests later and I have a first implementation.

The internal openwire DataStructure objects are now marshalled into the STOMP message body as JSON.  An example Advosiry sent to /topic/ActiveMQ.Advisory.Consumer.Queue.>:

{"ConsumerInfo": {
"commandId": 4,
"responseRequired": true,
"consumerId": {
"connectionId": "ID:pb-d-128-141-235-87.cern.ch-52535-1274794978077-4:1",
"sessionId": 1,
"value": 1
},
"destination": {
"@class": "ActiveMQQueue",
"string": "testConsumerAdvisory",
"null": {}
},
"prefetchSize": 1000,
"maximumPendingMessageLimit": 0,
"browser": false,
"dispatchAsync": true,
"noLocal": false,
"exclusive": false,
"retroactive": false,
"priority": 0,
"optimizedAcknowledge": false,
"noRangeAcks": false
}}


The code supports automatically supports all command objects that could be marshalled. One little problem is how the "destination" object is marshalled. Not sure why we get the @class in there.

Producing RPMs for Apache ActiveMQ

Edit (11-01-21) : See the more recent post on a new YUM repo and ActiveMQ 5.4.2 rpms.

All of the deployment we do is via RPM and a big gap for us has long been the lack of RPMs for FUSE Message Broker/ Apache ActiveMQ.

We've had our own hand-rolled rpms for a while now, and when I saw Dejan working on rpms via the maven plugin for ActiveMQ I offered to submit upstream what we have.  It's taken a bit of time to clean it up, but now it's all ready.

Our main deployment platform is Scientific Linux 5, based on RHEL 5.  We try where possible to submit things upstream via EPEL, and this means we need to comply with the Fedora packaging guidelines.  For Java you must build from source and you can't package dependencies in your rpm, so for a 'real' ActiveMQ rpm I'm going to have to build all the dependencies (and that includes all the camel dependencies too).  For such an old OS versions as RHEL5 I think this isn't worth it, but it's on my project list to try and do this for the upcoming RHEL6 release.

Anyway, what does this mean for ActiveMQ rpms now ?  Basically they're 'built' from a binary tarball coming from the Apache dist web server.  The rpm does some repackaging to make things a bit more linux-like in terms of directory locations and also applies some small patches (AMQ-2726 , AMQ-2727) which I'm waiting to get integrated upstream.

Everything is released for now on github and I hope it gets merged upstream at some point - keep an eye on this bug (AMQ-2105) for progress.  If you want to build for yourself, just grab the code and do a make

Built rpms for Centos5/RHEL5/SLC5 are on our build system.  Enjoy !

India & Nepal

I spend 3 weeks this January in Northern India and Nepal, starting in Delhi, going to Bodh Gaya, Varanasi, Kushinagar and Lumbini finishing up in Nepal in Kathmandu.  Too few days really, but definitely gave me a taste for the area.  Here's some pictures (flickr).