Menu
▾
▴
wrapper-user
|
From: Ole C. M. <ome...@sl...> - 2003-10-24 15:35:18
|
My application is an RMI server that I want to put under Wrapper (great tool btw) I do have on problem, currently we stopping the server will 1. Block further connections 2. Unregister from rmiregistry 3. Stay alive until no more current clients 4. Shutdown JVM Is it possible to mimic this so that the myapp stop command will only execute the shutdown method and then leave the JVM running until it decides on it self to go down? olec ---- Ole Christian Meldahl Information Management Development - Stavanger Schlumberger Information Solutions mailto: ome...@sl... +47 5194 6736 |
|
From: Leif M. <le...@ta...> - 2003-10-25 03:07:10
|
Ole,
Assuming that you have a way of telling when the JVM will really be
ready to exit,
there are a few ways to do this.
The easiest would be to register a shutdown thread which is started
when the JVM
starts to shutdown. It would then continue to run until all of your
clients have
completed.
The problem (feature) is that the Wrapper will by default kill the
JVM after about
30 seconds. To prevent this, you will need to tell the Wrapper that the
JVM needs
more time.
One way of doing this is to extend the shutdown timeout in the
wrapper.conf file.
This has the drawback of not knowing if the JVM needs more time or is
really hung
on shutdown however.
A better method would be to have your shutdown loop call
WrapperManager.signalStopping( Nms ); Each time this method is called, the
Wrapper will be sure to allow that much time before the Wrapper gives up
and kills
the JVM.
So if your shutdown thread calls WrapperManager.signalStopping(
30000 ) every
10 seconds or so, the JVM would always quit within 30 seconds of your
shutdown
hook completing even if the JVM got stuck for some reason.
Let me know if you have any questions. Allowing the JVM to run for
relatively
long periods of time after the JVM has been requested to exit is not the
norm. The
Wrapper supports it, but there are not many examples out there.
Cheers,
Leif
Ole Christian Meldahl wrote:
>
> My application is an RMI server that I want to put under Wrapper
> (great tool btw)
>
> I do have on problem, currently we stopping the server will
> 1. Block further connections
> 2. Unregister from rmiregistry
> 3. Stay alive until no more current clients
> 4. Shutdown JVM
>
> Is it possible to mimic this so that the
> myapp stop
> command will only execute the shutdown method and then leave the JVM
> running until it decides on it self to go down?
>
> olec
|
|
From: Ole C. M. <ome...@sl...> - 2003-10-27 08:49:10
|
At 17:54 24.10.2003, Leif Mortenson wrote: >Ole, > Assuming that you have a way of telling when the JVM will really be > ready to exit, >there are a few ways to do this. > > The easiest would be to register a shutdown thread which is started > when the JVM >starts to shutdown. It would then continue to run until all of your >clients have >completed. > > The problem (feature) is that the Wrapper will by default kill the JVM > after about >30 seconds. To prevent this, you will need to tell the Wrapper that the >JVM needs >more time. > One way of doing this is to extend the shutdown timeout in the > wrapper.conf file. >This has the drawback of not knowing if the JVM needs more time or is >really hung >on shutdown however. > A better method would be to have your shutdown loop call >WrapperManager.signalStopping( Nms ); Each time this method is called, the >Wrapper will be sure to allow that much time before the Wrapper gives up >and kills >the JVM. > So if your shutdown thread calls WrapperManager.signalStopping( 30000 > ) every >10 seconds or so, the JVM would always quit within 30 seconds of your shutdown >hook completing even if the JVM got stuck for some reason. When I read the docs this looked promising, but I have another requirement that I did not mention. I need to the restart action to work as well and I assume by using signalStopping I would not get the fresh server started until the previous stop action has completed satisfactory? > Let me know if you have any questions. Allowing the JVM to run for > relatively >long periods of time after the JVM has been requested to exit is not the >norm. The >Wrapper supports it, but there are not many examples out there. I understand, and I would not have implemented the server the way it is if I had a say, but it is a legacy app and hard to fix. The basic problem is that the server initializes it self with a lot of metadata from a database. It is not possible to reinitialize, one needs to restart the server. Since we use rmiregistry and stateful connections it is very easy to signal the running server to deregister and then register the new server. The previous server will then make sure to exit when all clients are logged off. Works smoothly. I'm not giving up just yet, so how will the wrapper like it if I change the script to do the following on the stop action: 1. Execute my own command: java SignalDeRegister server-name 2. Delete the pid file Will the subsequent start continue ok since the pid file is gone or will it contact ports to find an existing wrapper process? When the server decides it is time to close how can I signal the wrapper that the close is fine and there is no need to restart? System.exit(0)? Thanks for your help! olec >Cheers, >Leif > > >Ole Christian Meldahl wrote: > >> >>My application is an RMI server that I want to put under Wrapper (great >>tool btw) >> >>I do have on problem, currently we stopping the server will >>1. Block further connections >>2. Unregister from rmiregistry >>3. Stay alive until no more current clients >>4. Shutdown JVM >> >>Is it possible to mimic this so that the >>myapp stop >>command will only execute the shutdown method and then leave the JVM >>running until it decides on it self to go down? >> >>olec > > > > > >------------------------------------------------------- >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 ---- Ole Christian Meldahl Information Management Development - Stavanger Schlumberger Information Solutions mailto: ome...@sl... +47 5194 6736 |
|
From: Leif M. <le...@ta...> - 2003-10-28 07:38:34
|
Ole, > When I read the docs this looked promising, but I have another > requirement that I did not mention. I need to the restart action to > work as well and I assume by using signalStopping I would not get the > fresh server started until the previous stop action has completed > satisfactory? True. The Wrapper does not allow a second JVM process to be launched until the first JVM process has been terminated one way or another. This is critical for most applications to prevent conflicts with memory, ports and other resources. It would also be quite a bit more difficult for the Wrapper to manage multiple JVMs at once. >> long periods of time after the JVM has been requested to exit is not >> the norm. The >> Wrapper supports it, but there are not many examples out there. > > Let me know if you have any questions. Allowing the JVM to run for > relatively > > I understand, and I would not have implemented the server the way it > is if I had a say, but it is a legacy app and hard to fix. The basic > problem is that the server initializes it self with a lot of metadata > from a database. It is not possible to reinitialize, one needs to > restart the server. Since we use rmiregistry and stateful connections > it is very easy to signal the running server to deregister and then > register the new server. The previous server will then make sure to > exit when all clients are logged off. Works smoothly. > > I'm not giving up just yet, so how will the wrapper like it if I > change the script to do the following on the stop action: > > 1. Execute my own command: > java SignalDeRegister server-name > 2. Delete the pid file > > Will the subsequent start continue ok since the pid file is gone or > will it contact ports to find an existing wrapper process? When the > server decides it is time to close how can I signal the wrapper that > the close is fine and there is no need to restart? System.exit(0)? This will not work because the pid file is for the Wrapper process and not the JVM. Deleting the PID will allow you to launch a separate copy of the Wrapper which would in turn in launch its own JVM. You will most likely run into problems here as both would be trying to access some of the same resources because they use the same wrapper.conf file. What is preventing you from shutting down JVM instance 1 cleanly and then restarting the second JVM instance normally? Are you concerned about the period of time where the JVM is down? If you managed to get two JVMs running at the same time, you are going to have lots of timing issues trying to get them to switch over control. Sorry if I am missing what you are trying to do. Explain enough and I will catch on eventually. :-). Cheers, Leif |
|
From: Ole C. M. <ome...@sl...> - 2003-10-28 08:13:04
|
At 08:37 28.10.2003, Leif Mortenson wrote: >Ole, > >>When I read the docs this looked promising, but I have another >>requirement that I did not mention. I need to the restart action to work >>as well and I assume by using signalStopping I would not get the fresh >>server started until the previous stop action has completed satisfactory? > >True. The Wrapper does not allow a second JVM process to be launched >until the first >JVM process has been terminated one way or another. This is critical for most >applications to prevent conflicts with memory, ports and other resources. >It would also be quite a bit more difficult for the Wrapper to manage >multiple JVMs >at once. > >>>long periods of time after the JVM has been requested to exit is not the >>>norm. The >>>Wrapper supports it, but there are not many examples out there. >> >> Let me know if you have any questions. Allowing the JVM to run for >> relatively >> >>I understand, and I would not have implemented the server the way it is >>if I had a say, but it is a legacy app and hard to fix. The basic problem >>is that the server initializes it self with a lot of metadata from a >>database. It is not possible to reinitialize, one needs to restart the >>server. Since we use rmiregistry and stateful connections it is very easy >>to signal the running server to deregister and then register the new >>server. The previous server will then make sure to exit when all clients >>are logged off. Works smoothly. >> >>I'm not giving up just yet, so how will the wrapper like it if I change >>the script to do the following on the stop action: >> >>1. Execute my own command: >>java SignalDeRegister server-name >>2. Delete the pid file >> >>Will the subsequent start continue ok since the pid file is gone or will >>it contact ports to find an existing wrapper process? When the server >>decides it is time to close how can I signal the wrapper that the close >>is fine and there is no need to restart? System.exit(0)? > >This will not work because the pid file is for the Wrapper process and not >the JVM. >Deleting the PID will allow you to launch a separate copy of the Wrapper >which would >in turn in launch its own JVM. You will most likely run into problems >here as both >would be trying to access some of the same resources because they use the same >wrapper.conf file. 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 The logfile can become muddled as well but I guess I can fix that by setting it to be something-timeofstart.log when invoking? If the JVM can make sure that the wrapper dies with it shouldn't be ok to have to wrapper running at the same time? I probably need to disable the automatic restarting, can I do that dynamically when I get the stop signal in my JVM? By using the signalStopping method? >What is preventing you from shutting down JVM instance 1 cleanly and then >restarting the >second JVM instance normally? Are you concerned about the period of time >where the >JVM is down? Key point is to not interrupt client applications by killing the existing server. The client app is about data access operations, building transactions and so on, so the current mode of operation is to notify the user that a fresh server is started but allow for them to complete what their doing and switch when it suits them. This then avoids us having to move the stateful connections from the old server to the new. Restarting is a fairly frequent thing as it is the only way to refresh all the metadata we have stored in a database. Like I mentioned before this is legacy app so this all works smoothly, and is also not something I can easily fix. I would have liked to take advantage of your cross platform scripts, nice config mechanism and the ability to protect the running server with your monitoring functionality, but alas.... >If you managed to get two JVMs running at the same time, you are going to >have lots of >timing issues trying to get them to switch over control. > >Sorry if I am missing what you are trying to do. Explain enough and I >will catch on >eventually. :-). I know I'm stretching the purpose a bit but I really like to adopt Wrapper for my app. Thanks for your help! olec >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 ---- Ole Christian Meldahl Information Management Development - Stavanger Schlumberger Information Solutions mailto: ome...@sl... +47 5194 6736 |
|
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
|
|
From: Prashant R. <pra...@pr...> - 2003-10-29 05:07:48
|
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 |
|
From: Leif M. <le...@ta...> - 2003-10-29 05:34:39
|
Prashant Reddy wrote: >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+? > > Maybe deprecated is the wrong word. It is no longer required. I kept having people ask about warning caused when they tried to run multiple copies of the Wrapper with the same port. The socket is only used internally so there is not really any reason for the user to have to specify it. As of version 3.0.5, the wrapper will use the value of wrapper.port if it is specified. Otherwise if will look for the first available port over port 32000. I use the high number to avoid possible conflicts with any user defined well known ports. This is up in the range that ports are dynamically pulled from by the system. There should be no loss of functionality here. Only a simplification for new users. Cheers, Leif |
