Publish Tomcat/tcServer lifecycle events into the cloud with RabbitMQ
Once of the common tasks in any cloud environment is to manage membership lists. In the case of a cloud of Tomcat or SpringSource tcServer instances, I wrote a simple JMX MBean class that exposes my tcServer instances to RabbitMQ and serves two functions:
- Expose the calling of internal JMX methods to management tools that send messages using RabbitMQ.
- Expose the Catalina lifecyle events to the entire cloud.
To maintain a membership list of tcServer instances, I now just have to listen to the events exchange and respond to the lifecycle events I'm interested in:
def members = []
mq.exchange(name: "vcloud.events", type: "topic") {
queue(name: null, routingKey: "#") {
consume onmessage: {msg ->
def key = msg.envelope.routingKey
def msgBody = msg.bodyAsString
def source = msg.envelope.routingKey[msgBody.length() + 1..key.length() - 1]
println "Received ${msgBody} event from ${source}"
if ( msgBody == "start" ) {
members << source
} else if ( msgBody == "stop" ) {
members.remove(source)
}
return true
}
}
}
Starting and stopping the tcServer instance yields this in the console:
Received init event from instance.id
members=[]
Received before_start event from instance.id
members=[]
Received start event from instance.id
members=[instance.id]
Received after_start event from instance.id
members=[instance.id]
Received before_stop event from instance.id
members=[instance.id]
Received stop event from instance.id
members=[]
Received after_stop event from instance.id
members=[]
It seems to me one of the defining characteristics of cloud computing versus traditional clusters is the transparency between runtimes and what used to be separate servers. To that end, I've exposed the inner workings of my tcServers both to other servers of their kind in the cloud, and to sundry management and monitoring tools I may choose to write in the future.
If you're concerned with security, opening up the JMX MBeans of your server may give you pause. Fair enough. In my case, that's not as big of a concern because these servers are protected from the outside world. Only LAN and WAN users can access these servers, so I don't mind exposing JMX methods to trivially-secured message brokers, particularly if it gives me this kind of inexpensive and direct control over the services I'm exposing to the cloud.
