>> I need some framework for centralizing the control. They are currently
>> running as chron jobs or just manually initialed. I'd like to be able to
>> monitor, start, and restart the from a control center.
>This sounds very similar to the Turbine Scheduler Service. Have you looked
>at it? (http://jakarta.apache.org/turbine/services/scheduler-service.html)
Yes, I've looked at it. I have concerns about the vm dependency. I'd
rather have jobs in their own vms:
>
> Some service could start the rmi activation daemon on a machine and then
> the control could call and spawn each process in its own vm. It could
then
> send monitoring requests and issue shutdown and restart commands. Would
> this be an ad hoc use of the framework?
>
The problem with my solution is that is a service vm locks up I can't really
kill it. I'll need to kill the process somehow. I don't feel like going to
the machine and running kill.
>This is exactly the type of thing that I was looking at creating for my
>application (Tambora). It currently uses a lot of Turbine scheduled jobs
to
>move information around the application, kind of like what you are doing.
>These jobs can run under different JVM/Turbine applications.
So I could group services to run in some vm running a turbine instance. And
then control these turbines from another source.
>I also need the ability to stop and start my jobs remotely to so I was
>thinking of creating an XML-RPC handler for Turbine's XML-RPC service that
>will allow authenticated calls to a remote Turbine application to
>shutdown/startup/restart the Turbine Scheduler Service and also allow the
>adding/removing of jobs in a job queue.
I'm not sure about the value of xml-rpc for intrasystem control. It's a
thought. I need to to think aobut it. An activatible service framework
sounds so appealing though.
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
