|
|
| Author |
Message |
|
| Guest |
Posted: Sat Sep 01, 2007 6:21 am |
|
|
|
Guest
|
Hi,
I was wondering if there are any plans or ideas regarding Java-controlled
server startup/shutdown? I understand that the server is running in a
separate process which would more or less require a machine-local
configuration, but nevertheless a Java-based control mechanism for
starting/stopping/pinging a server on the local machine would IMHO be very
handy. Ideas? Suggestions? I just want to make sure I don't start writing
stuff that is already floating around somewhere.
thanks
Holger
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Mon Sep 03, 2007 9:36 am |
|
|
|
Guest
|
Holger
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.
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?
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?
alexis
On 9/1/07, Holger Hoffst |
|
|
| Back to top |
|
| Guest |
Posted: Tue Sep 04, 2007 11:31 am |
|
|
|
Guest
|
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
> 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!
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Wed Sep 05, 2007 10:55 am |
|
|
|
Guest
|
Holger,
Thanks for your detailed reply.
On 9/4/07, Holger Hoffst |
|
|
| Back to top |
|
| Guest |
Posted: Wed Sep 05, 2007 3:53 pm |
|
|
|
Guest
|
Alexis Richardson wrote:
>> 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
I'm all for retrotranslator but it's not that easy since ProcessBuilder
and friends are partially JVM/JDK specific and currently not retrozapped
(I just checked), probably for exactly that reason. It can only go so far..
>> 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
Will do! I was delighted when I looked at the source after unpacking:
"..but where is the rest?..oh.".
best
Holger
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|
|