J. Brisbin

Just another Wordpress.com weblog

Groovy DSL for RabbitMQ

leave a comment »

I’ve been using RabbitMQ for several months now, trying to set up a virtual private cloud environment so we can start moving away from copying text files to transmit data between servers. The RabbitMQ servers also broker messages between components within the cloud that don’t need to be tightly coupled together.

This works great for code that’s running inside an application, but what if you need to delete some durable queues you created because you’ve second-guessed your naming scheme? I created the Groovy DSL (Domain-Specific Language) for just such purposes. It allows you to write small maintenance applications in Groovy and tie them to your RabbitMQ server. Consider the following example:

mq.on error: {err ->
  err.printStackTrace()
}

mq {channel ->

  channel.queueDelete("vcloud.session.dev1")
  channel.queueDelete("vcloud.replication.dev1")
  channel.queueDelete("vcloud.source.dev1")
  channel.queueDelete("vcloud.session.dev2")
  channel.queueDelete("vcloud.replication.dev2")
  channel.queueDelete("vcloud.source.dev2")

  //channel.exchangeDelete("vcloud.session.events")
  //channel.exchangeDelete("vcloud.replication.events")
  //channel.exchangeDelete("vcloud.source.events")

}

mq.exchange(name: "test", durable: false, autoDelete: true) {
  // Named, non-durable queue
  queue name: "test", routingKey: "test.key", {
    consume tag: "test", onmessage: {msg ->
      log.info(msg.bodyAsString)
    }
  }
}

In this example, I’m using the built-in command-line functionality and invoking this groovy script like:

# mqdsl -f delete-exchanges.g

This script:

  1. Places an error handler on the event stack “mq.on error: <my error closure>”, which will be called any time an error occurs.
  2. Deletes a bunch of leftover queues from previous test runs by accessing the channel object directly.
  3. Places a consumer on a non-durable queue and exchange and waits for an incoming message. When that message is received the body is printed to the log file (by default $MQDSL_HOME/logs/mqdsl.log) and, if your closure returns “false” or null, the script exits (returning “true” or non-null causes the consumer to keep waiting for new messages).

It seems to work fine for me, but I can’t guarantee it will be that way in your situation. I would be interested to hear feedback, though, if you have problems.

It’s Apache 2.0 licensed and available on GitHub: http://github.com/jbrisbin/rabbitmq-dsl

Instructions for building, installing, and some basic usage instructions are in the README, and in the GitHub wiki.

Advertisements

Written by J. Brisbin

April 8, 2010 at 6:52 pm

Posted in The Virtual Cloud

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: