Hi, I see, thanks for pointing it, but what about the ShutdownHook isn't it there to prevent such behaviour and to wait for stopping.... Aha I see it while I'm writing :) the ShutdownHook just waits the bundles to be stopped and there are stopped and its different from ending all threads created by the bundles and so the Main ends and calls System.exit.
Thanks once again for pointing it damencho On Thu, Sep 16, 2010 at 5:39 PM, Karl Pauls <[email protected]> wrote: > Are you maybe using just the normal Main method of the main bundle? In > that case, we do call system exit in there after the framework is > shutdown: > > http://svn.apache.org/repos/asf/felix/trunk/main/src/main/java/org/apache/felix/main/Main.java > > regards, > > Karl > > On Thu, Sep 16, 2010 at 3:51 PM, Damian Minkov > <[email protected]> wrote: >> Hi all, >> >> thank you all for the suggestions, I was checking them but without any >> change. So I made a simple test case that reflects our behaviour. Find >> it attached. >> >> The example just starts felix, then one bundle is started which waits >> for 2 seconds then calls the stopping the same way we do and when >> bundle stop method is called it creates a non daemon Thread which will >> wait for 5 seconds. The whole execution must take at least 8 seconds. >> But it takes no more then 3 or 4(including ant tartgets). >> Here is the output of one execution: >> run: >> >> [java] Now wait 3 sec. >> [java] start the felix stopping >> [java] Stopped! >> [java] Now wait 5 sec. before end >> >> BUILD SUCCESSFUL >> Total time: 3 seconds >> >> To run it just place felix Main jar in lib folder and do "ant run" >> (I've tested with org.apache.felix.main-3.0.2.jar). >> >> Thanks >> damencho >> >> >> On Thu, Sep 16, 2010 at 3:13 PM, peter lawrey <[email protected]> >> wrote: >>> The JVM will also die if it crashes. E.g. you might have a JNI library you >>> are using and it has a bug in its shutdown/unload. Have a look for a >>> hs_err_pid*.log file in the working directory of your instance. >>> >>> Otherwise, you really are calling System.exit() if not directly. In which >>> case you should be able to debug your instance and breakpoint this call to >>> see if it being called. >>> >>> AFAIK, Even if all your thread are daemons, felix has threads which are not >>> so this is unlikely to be the cause of your problem. >>> >>> -----Original Message----- >>> From: Felix Meschberger [mailto:[email protected]] >>> Sent: 16 September 2010 12:40 >>> To: [email protected] >>> Subject: Re: Stopping and non daemon threads >>> >>> Hi, >>> >>> Well, the JVM can of course only exit after all non-daemon threads have >>> been stopped or after a call to System.exit(int). >>> >>> Now, if you have a bundle which starts a thread, you must make sure to >>> stop that thread when the bundle stopped. Otherwise you create a memory >>> and performance leak if the bundle is repeatedly started, stopped, >>> updated etc. >>> >>> Regards >>> Felix >>> >>> Am 16.09.2010 13:01, schrieb Damian Minkov: >>>> Hi, >>>> >>>> I'm currently looking at a problem in sip-communicator on shutting >>>> down. To shut down we stop bundle with id 0. But in some of our >>>> bundles we need to do some stuff which involves network operations, >>>> and so we create a non daemon Thread in order to do it. But just a >>>> little after the Thread is created and started the application exits >>>> and don't finish all the operations. >>>> Any ideas why this happen or just am I missing some configuration? >>>> >>>> Thanks >>>> damencho >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Karl Pauls > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
