[rabbitmq-discuss] Server control classes in Java

[Holger Hoffstätte]

Hi,

Alexis Richardson wrote:
> Your timing is excellent.  This is on our to do list, but we have not
> begun addressing it.  If you would be willing to write something then
> we would certainly look at including it.

It was more of a random idea.. :)

This might be useful for embedding the server and also more Java-centric
testing without having a backup human fiddle with an external server.
For now I was only thinking of starting/stopping an instance on the local
machine..remote activation is a different animal altogether and should
probably tie in with deployment/management mechanisms. Maybe a Jini
service :-D

> If you are keen to start the ball rolling, please can you comment on
> the following issues --
> 
> 1.  Should a Java-based start/stop/ping control be wrapped using some
> standard enterprise Java API or framework?

I'm not aware of any extra APIs for that since external process control is
very system-dependent. Sadly it seems most prople just end up hardcoding
Strings into their apps until it sort of works..
I think you are targeting JDK 1.4 compliance with the Java classes, right?
That rules out the new 1.5+ ProcessBuilder classes, but it's not too big a
problem. The differences between Unixen and Windows are probably a bit
trickier. Fortunately such a server manager does not really need much
interaction with the external process; the usual Runtime.exec() stuff can
be difficult to get right since stdin/out/err need to be read
asynchronously or stuff starts blocking/hanging etc.

> 2.  To a degree, the commands to boot the Rabbit server are O/S and
> package dependent.  What is the least painful way to abstract this
> away?

No idea yet. I have JDK 1.4 cross-platform helper classes to read OS
environment variables (Windows and Unix with sh/bash/csh/zsh, all of which
are different!) and e.g. parse VM property definitions from strings (the
-Dxxx -Dfoo=bar stuff, which was surprisingly difficult) since we had
similar problems in Mule.

I guess platform-specific subclass instances that get returned from a
RabbitMQServerManagerFactory could do the trick - then Windows/Unix stuff
can be hidden behind common methods. The actual communication with the
server for pings, stats etc. would be via the regular Java AMQP protocol,
right? Once we have such a server manager we might think about exposing
the server stats and operations via JMX.
I guess the common operations for the server manager would initially just
be start, stop and maybe notification/handling on unexpected process
death. Also an optional VM shutdown hook could be handy, to make sure both
processes go together.

cheers
Holger

PS: Warning and Disclaimer: so far I've used rabbitmq exactly once for 5
minutes and have not even started reading my new Erlang book yet!