Original Source

Glen Smith writes about his experience with Grails, JMS and OpenMQ. As you probably know, Glen is responsible for groovyblogs.org , which has been recently upgraded to a messaging architecture.

I’ve just finished converting groovyblogs over to a (largely) message driven architecture. I’m a bit of an JMS noob, but the adventure has been fantastic, and it’s time to write some stuff down. The reason I’m even interested in a messaging is for the acquisition of feed xml and thumbnails. I presently do the former in-process in the app server, and the later via Groovy XML-RPC to a Thumbnail Server running locally.

My re-design involves creating four queues: urlRequest, urlResponse, thumbnailRequest, thumbnailResponse. The webapp will put the requests on the request queues, then an external process will deliver source the the thumbnails and feed data (external to the app server) and deliver them on the response queues. All the db action remains in the webapp, so all my hibernate/GORM goodness can continue as usual.

First off was choosing an MQ provider. ActiveMQ seems to have all the mindshare, and was easy to install, but I had quite a bit of trouble actually getting it working correctly. My clients would frequently drop their connections, messages were undelivered since I terminate JmsTemplate connections incorrectly, messages were not delivered on reconnect, and it was generally unforgiving to my JMS noob-ness. I’m sure it’s not ActiveMQ’s fault. But it wasn’t a great experience for me. YMMV.

Then I found out that OpenMQ ships embedded right into Glassfish, so I made the switch and have been happy every since. When I’m running outside of the container ("grails run-app"), I just run a standalone copy of OpenMQ to test against, and when I deploy to Glassfish, I just use the embedded one. Sensational! OpenMQ ships with a funky Swing admin tool, but the only thing it didn’t have was a funky Queue content browser (like the Web one that ships with ActiveMQ, but I setup Hermes-JMS and now I can happily browse the contents of both local and remote queue.).

After settling on OpenMQ as his MQ provider of choice, Glen then turned to the Grails side of the equation. Thanks to the thriving Grails plugin community he didn’t waste too much time integrating JMS into groovyblogs. Enter the JMS Plugin for Grails . It makes the job fairly easy, after all it follows the Grails ways, so you can be sure you will find a fair share of convention over configuration, mapped closures, metadata-as-properties and extended artifacts to get yourself on the right track.

Ok. I had my JMS platform, now it was just a matter of getting the data into and out of those queues. Enter the JMS Plugin . This plugin rocks so hard! Define a service that has an expose = ['jms'] and life will be good for you. To listen on the queue, just define an onMessage closure. You can use naming conventions to map to existing queue names, but in my case I had specific ideas on what I wanted the queue to be called, so I set an explicit ‘destination’

All the messages I pass around are normal java.util.Map objects, which makes it easy to ship a bunch of payload at once. Once that’s done, anything that ends up on the thumbnailResponse queue will get automatically passed to my onMessage routine.

This article describes how to setup the environment to get messages on the queue, Glen promised to write a follow-up describing how to get messages off the queue by some processing POGOs.

Tags: Glen Smith, Grails