|
From: <TEI...@te...> - 2006-06-19 11:55:14
|
Hi, again!
Looking into WrapperStartStopApp I've noticed the 'stop' method is suppos=
ed to wait for all non-daemon threads to complete depending on=20
a boolean attribute called m_stopWait, which corresponds with the first par=
am passed to WrapperStartStopApp right after the shutdown class=20
param.
if ( m_stopWait )
{
int threadCnt;
while( ( threadCnt =3D WrapperManager.getNonDaemonThreadCou=
nt() ) > 1 )
{
if ( WrapperManager.isDebugEnabled() )
{
System.out.println( "WrapperStartStopApp: stopping.=
Waiting for "
+ (threadCnt - 1) + " threads to complete." );
}
try
{
Thread.sleep( 1000 );
}
catch ( InterruptedException e )
{
}
}
}
The logfile I sent in the previous mail was produced by Wrapper logging i=
n DEBUG level, so this sentence
- System.out.println( "WrapperStartStopApp: stopping. Waiting for "+ (=
threadCnt - 1) + " threads to complete." );
should have been executed, which wasn't the case.
I think I've configured WrapperStartStopApp properly so, perhaps, the ori=
gin of the problem might be when setting m_stopWait, or into=20
WrapperManager.getNonDaemonThreadCount()
What do you think?
=20
----Mensaje original----
De: TEI...@te...
Recibido: 19/06/2006 11:10
Para: <wra...@li...>
Asunto: Re: [Wrapper-user] WrapperStartStopApp stopping service=09premature=
ly?
Hi!
I tryed configuring the following variables with no results. The logging ou=
tput is truncated right after the manager has finished.
wrapper.shutdown.timeout=3D0
wrapper.jvm_exit.timeout=3D0
I attached a logfile. I can't get any clues from it, except that the wrappe=
r seems to do its job.
My question is, when does WrapperStartStopApp stop the service?
Kind regards
----Mensaje original----
De: da...@sm...
Recibido: 17/06/2006 6:09
Para: <wra...@li...>
Asunto: Re: [Wrapper-user] WrapperStartStopApp stopping service=09premature=
ly?
(sorry for the personal post - stupid webmail client)
You mention that your servers logging output is truncated. I guess =20
this means that your server was forceably closed by the Wrapper. This =20
normally happens when the wrapper has been notified of the stopping, =20
but the actual app has not stopped within the expected time period. =20
Check out the .conf property wrapper.shutdown.timeout or possibly =20
consider calling WrapperManager.signalStopping(...) every few seconds.
To further get an understanding on what is going on under the bonnet, set t=
he
wrapper.debug to TRUE and inspect the results wrapper log file. This =20
will tell you exactly why the wrapper has shut down your application, =20
and will give you a better idea on how to solve it.
You could post it as well for us to see if we could help.
Cheers,
Davy Boy Out...
Quoting "TEI...@te..." <TEI...@te...>:
>
> Thanks, David!
>
> I don't think that's the case. I'll try to draw it with more =20
> detail. I developed my application without Wrapper in mind in the =20
> first
> instance. Lets call the first app "Server" and "Manager" would be =20
> the second one.
> Server is an event driven application, there's an event queue from =20
> where it pops events. When a "shutdown" event is read, Server stops
> reading events, asks avery of its working threads (non daemon =20
> threads) to stop (they will close connections) and waits until all =20
> of them
> have stopped (this doesn't take more than 5s).
> Server logs almost every meaningful event/action it takes.
>
> The whole system, running alone, outside the wrapper, would log =20
> something like this.
>
> 1. Server: Start
> 2. Server: Launching a "connector" thread to handle incoming connectio=
ns.
> 3. Server: Trying to connect to other applications (more threads =20
> and connections)
> ...
> 4. Server: Receiving an incoming connection -> a worker thread is =20
> launched in order to handle it.
> ...
> At this moment a number of (non daemon) threads are running.
> ...
> 5. Manager: Connected to the server, sent a shutdown command, =20
> closed connection and finish.
> 6. Server: ( ... keeps doing its thing ...) A "shutdown" =20
> command/event was read.
> 7. Server: Ask avery single thread to stop (threads will close =20
> connections as soon as possible).
> 8. Server: Wait for every single thread to stop.
> 9. Server: Finish
>
> The whole system, running into the wrapper
>
> 1. Server: Start
> 2. Server: Launching a "connector" thread to handle incoming connectio=
ns.
> 3. Server: Trying to connect to other applications - more threads =20
> and connections
> ...
> 4. Server: Receiving an incoming connection -> a worker thread is =20
> launched in order to handle it.
> ...
> At this moment a number of (non daemon) threads are running.
> ...
> 5. Manager: Connected to the server, sent a shutdown command, =20
> closed connection and finish.
> 6. Server: ( ... keeps doing its thing ...) A "shutdown" =20
> command/event was read.
> At this moment Manager is already dead and WrapperStartStopApp =20
> seems has decided to kill Server too, cause logging output was
> truncated
>
> I added a Thread.sleep(5000) to make sure Manager's death was =20
> after Server's, the resulting logging output was the same as if the =20
> system
> were running alone, that is, not into WrapperStartStopApp.
>
> Further comments, please!
>
>
>
> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, =20
> r=C3=A1pido, fiable.
>
>
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r=C3=A1pido,=
fiable.
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r=C3=A1pido,=
fiable.
|