Re: [Wrapper-user] Stopping a JVM, but leaving it around?

[Prashant R. <pra...@pr...>]

Leif,
>     The Wrapper will have no problems having 2 copies of itself running at
> the same time.
>     The following is an idea (untested)
We use this configuration to run two instances of our server application lot
of times, I was apprehensive of both instances writing to same .log
file..but everything seems to be working fine even with one log file.
If wrapper.port property is deprecated..Does it mean it will not be
configurable. The default value will be what, 1777+?

Thanks
Prashant
----- Original Message -----
From: "Leif Mortenson" <le...@ta...>
To: <wra...@li...>
Sent: Tuesday, October 28, 2003 3:23 PM
Subject: Re: [Wrapper-user] Stopping a JVM, but leaving it around?


> Ole,
>     Hmmm.  This is a difficult one.  I think I understand the issues now.
> The Wrapper is only capable of controlling one JVM at a time.  In order
> to do what you are trying to do, you are going to need to have 2 JVMs
> running at the same time.   So if you want them controlled by the Wrapper
> that is going to mean 2 copies of the Wrapper.
>
>     The Wrapper will have no problems having 2 copies of itself running at
> the same time.
>     The following is an idea (untested)
>     Create two shell scripts that are copies of the one provided by the
> Wrapper
> called serverA.sh and serverB.sh.   These will be used to control each of
2
> Wrapper invocations.  Modify them to have different app names and this
> different pid file names as well.  They also need to be modified to
> point to two
> config files wrapperA.conf and wrapperB.conf.   Each of these config files
> will do nothing but include the main wrapper.conf file AND declare their
> own log files wrapperA.log and wrapperB.log.
>
> wrapperA.conf
> # paths relative to the location of the wrapper binary
> #include ../conf/wrapper.conf
> wrapper.logfile=../logs/wrapperA.log
>
> wrapperB.conf
> #include ../conf/wrapper.conf
> wrapper.logfile=../logs/wrapperB.log
>
>     You should now be able to control each of the servers as single apps.
> Once one is running, it will restart itself if it fails due to an error.
>
>     Now for the work.   Create a new shell script that accepts all of the
> command arguments accepted by the wrapper shell scripts.
>     The first thing that this new script will do is to check for the
> existence
> of a serverA.pid and/or serverB.pid file.
>     If you call the script with the "start" command, it should give an
error
> if either pid exists. Otherwise it will always call "start" on the serverA
> script.
>     If "stop" is called, it will call "stop" on serverA and/or serverB
> scripts.
>     If "dump" is called, it will call "stop" on serverA and/or serverB
> scripts.
>     If "restart" is called then it will give and error if both the
> serverA.pid and
> serverB.pid exist.   If only one exists, then "stop" will be called on
> that script
> and "start" will be called on the other.
>
>     This should work fairly well for you.   By calling restart, you will
> be able
> to reload your application on demand and keep the second copy running
> until it can be shutdown.  But if the active JVM crashes in the middle
> of the
> night, it will be restarted by its controlling Wrapper.
>
> > That would be the port number? Your code seem to verify that the port
> > is free and then increment, if not I can have the script increment it
> > within a range
>
> Actually, as of version 3.0.4, manual use of the wrapper.port property is
> deprecated.   If you still have it in your wrapper.conf file, you should
> remove
> it.
> I was referring to the wrapper.log file as well as any resources used by
> your
> application.  You will still have to be careful about those on your
> own.  Take
> advantage of the wrapperA.conf and wrapperB.conf files to set different
> system properties etc.
>
> > I know I'm stretching the purpose a bit but I really like to adopt
> > Wrapper for my app. Thanks for your help!
>
> That is why the Wrapper has continued to grow.   While I have used several
> newer features once they were implemented.  The Wrapper pretty much did
what
> I needed a year a go.   I am always amazed at some of the ideas that
> users come
> up with.  It is a tribute to the benefits of opening up a project.
> There is a definite
> large cost in time and thus money to support users for free (Offset by
> generous
> donations from users that want say thanks.  Hint hint :-D)  But there
> are also
> benefits from having so many users look at the code.  I had to support a
> user on
> Solaris last year.  I personally only have used Linux and Windows so it
> would
> have involved a huge investment in testing before I could have used it.
> But thanks
> to the user base and their experience with using the Solaris version, I
> knew that
> it could be relied on.
>
> Cheers
> Leif
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user