“Daddy grips the wheel and stares alone into the distance.
He knows that something somewhere has to break” – The Police

I recently attended SpringOne 2GX and had a great time.  The folks behind Spring, Groovy, and Grails are fantastic.  Go find a NFJS event and be dazzled.  During one session I learned about RabbitMQ, a recent acquisition of SpringSource.  This is an impressive project done in only 12,000 lines of code!

I’m greatly intrigued by a message queuing system.  My only experience is as a gateway to a mainframe system.  Not exactly a keen architectural strategy as much as “that’s how you gotta do it.”  So I’ve seen something there, but have struggled to find a good use.

But I feel like I’ve found something!  We have many applications that have a common need to interface with an external system via SOAP.  This is an expensive operation and is currently handled synchronously.  Ah HA! Toss it behind a queue and make it asynchronous and regain some performance.  This call doesn’t need to have a response so the application doesn’t have to wait for the return!

Now throw in other ideas like an enterprise language-agnostic logging system, and step that up a bit with a destination for critical errors  to be stored for investigation and triage.  I think I now have a trifecta of ideas, and enough critical mass to justify revving up a new service!

What are your thoughts and experiences with asynchronicity?


5 Responses to “Asynchronicity”

  1. Leon Oosterwijk Says:

    using messaging as your system backbone has a lot of traction. See linked in’s kafka ( ) or this excellent presentation on how writing immutable objects and saving snapshots creates high volume transational systems ( )

  2. jonwolski Says:

    Because I enjoy your response as I prod you toward Scala, I have to mention that, while 12,000 LOC is impressive, Kestrel (used by Twitter) is only 1500 lines of Scala 😉

    Scala, Erland, either way, functional programming for the win

  3. jonwolski Says:


  4. leon oosterwijk Says:

    there’s a lot of talk about LOC of java vs. scala etc. i’m not yet convinced that less lines of code makes for more readable (or better) programs. I’ve hacked on some pretty impressive perl apps, which were very terse and very unmaintainable. If you say ‘but that was procedural and this is functional’, i caution you that adding a different paradigm (and arguably a more difficult one to grasp) is not likely to make the terseness easier to understand. i’m not trying to bash scala or FP, but terseness is not always better.^_^

  5. jim siegienski Says:

    Pure LOC on its own doesn’t mean much to me (e.g. obfuscated perl), I was more impressed with the idea of choosing the right tool for the job. If you can do that and code succinctly I think it’s a big win.

    Less code equates to fewer chances to introduce bugs and issues. Executed well this should lead to readable code which should also reduce coding and logic errors. Again, the big key here is execution as you’ve alluded.

    All things being equal, I’ll lean towards brevity.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: