Re: [Wrapper-user] configuring, installing and launching services from within a wrapper service

[Leif M. <lei...@ta...>]

Christopher,
The Professional Edition contains a set of WrapperManager.exec methods
which are a much improved version of the Runtime.exec methods.  They
allow the following on top of what the Java implementation does.

1) Low memory forks.  This is a big problem on Solaris systems when
the JVM is large.

2) Managed child processes.   The Wrapper will make sure that any
children launched by the JVM using the WrapperManager.exec method will
be cleaned up after the JVM exits for whatever reason.  This is very
important when the JVM exits or crashes unexpectedly.   It is possible
to tell the Wrapper not to monitor a particular child process if you
want it to stay running.

3) We do a bit more graceful shutdowns of child processes.  We first
try to shut them down nicely with a CTRL-C or TERM signal.  Then after
a timeout the child is forcibly killed.  Runtime.exec simply kills it
immediately.  Currently the timeout is 5 seconds, but the next release
already has the ability to configure this timeout.

This lets you do some very powerful multi process configurations.  It
does have the drawback that the children will always be reset if the
parent JVM is restarted.   If each Wrapper is a full installed service
then they are each a bit more independent.   Both designs have their
benefits.

Cheers,
Leif

On Wed, Sep 22, 2010 at 12:35 AM, Christopher Taylor <ct...@co...> wrote:
> Leif,
>
> Thanks for the response. Let me clarify the scenario we're facing:
>
> We have a single, wrapper-managed service which should be in control of a bunch of other processes (each wrapped by wrapper, running in their own JVMs).  There should only be a single service installed in the OS, the number of subprocesses may vary between deployments.
>
> Currently, we're thinking about simply launching the sub-wrapper instances using i.e. Runtime.exec("wrapper-subcomponent.bat") and making sure to terminate them when the master service is terminated.
>
> Are there any interactions between the multiple wrapper instances we need to be aware of when a wrapper service launches other wrapper instances? Another challenge we are facing with our approach is how to signal the service wrapper managed sub processes that they should be gracefully terminated, IOW how they would still get some seconds to clean up.
> Process.destroy will most likely immediately kill the wrapper sub process, won't it? Do you have any API that is better suited launching/controlling multiple service wrapper managed subprocesses than java.lang.Runtime?
>
> We are using the licensed community version of ServiceWrapper.
>
> Regards,
>  --Christopher
>
>> -----Original Message-----
>> From: Leif Mortenson [mailto:lei...@ta...]
>> Sent: Tuesday, September 21, 2010 1:46 AM
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] configuring, installing and launching services from within a wrapper
>> service
>>
>> Christopher,
>> The Wrapper does not directly provide a way to install new services,
>> but you can start, stop, pause, resume, etc. Services which are
>> already installed.   This is done using the
>> WrapperManger.sendServiceControlCode method.  See the Javadocs:
>> http://wrapper.tanukisoftware.com/doc/english/javadocs.html
>>
>> Before you can make use of these service methods however, you will
>> need to install a Security Manager in the JVM:
>> http://wrapper.tanukisoftware.com/doc/english/security-model.html
>>
>> Please let me know what you find missing here, as well as how you
>> would ideally like to see it work.
>>
>> Cheers,
>> Leif
>>
>> On Tue, Sep 21, 2010 at 3:57 AM, Christopher Taylor <ct...@co...> wrote:
>> > Hi List,
>> >
>> >
>> >
>> > Sorry if this has been asked before, the list search on sf didn't work for
>> > me.
>> >
>> >
>> >
>> > Is there an API in wrapper that allows me to configure, install and run/stop
>> > services in separate JVM instances from within my program? I could generate
>> > and exec wrapper scripts, but I'd like to know whether there is an API for
>> > this.
>> >
>> >
>> >
>> > I'd appreciate any pointers.
>> >
>> >
>> >
>> > Regards,
>> >
>> >   --Christopher