[rabbitmq-discuss] Server control classes in Java

[Alexis Richardson]

Holger,

Thanks for your detailed reply.


On 9/4/07, Holger Hoffstätte <holger at wizards.de> wrote:
>
> 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..

I understand.  That would certainly be very useful.



> > 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..

Bootstrapping from there would be perfectly OK for a first pass.


> 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.

We are currently targetting 1.5 with retrotranslator functionality.
So - go for it :-)



> > 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.

Anything you have already to hand, would be useful at this stage.



> 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.

Sounds sensible.


> The actual communication with the
> server for pings, stats etc. would be via the regular Java AMQP protocol,
> right?

Initially yes.  We've thoughts on optimisations for the future -- I'd
ask Tony to articulate the options there if people want to discuss
these.


> 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.

All good.  If we can get this to work we can then do all sorts of
fancy stuff later, such as using the queues to present management
hooks.  But your starting point would in and of itself be extremely
useful.


>
> 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!

Hopefully you shouldn't have to read it, but do please let us know how
you get on ;-)

alexis




-- 
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)