|
From: Leif M. <le...@ta...> - 2003-10-28 09:54:14
|
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
|