felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferry Huberts <maili...@hupie.com>
Subject Re: Giving up on in process update... suggestions for how to structure separate JVM update?
Date Tue, 14 May 2013 14:51:12 GMT

On 14/05/13 16:46, Dan Gravell wrote:
> Hmmmm, sorry, don't want to misrepresent things... In neither case do you
> *explicitly* start threads.
> JNotify's threads are started by the class initialisers... so load the
> class (as you do when you add a 'watch' via a static method for a
> directory) and the thread starts.

My fork doesn't do that and has proper activators and deactivators.

You might be interested in it and add Mac and Windblows support???

> Lift's are started as part of its HTTP request handling. I managed to patch
> it to stop all the threads upon shutdown of its surrounding servlet
> container (I use Jetty) but this is just code I will have to maintain going
> forward with new releases.
> Neither behaviour is particularly desirable but JNotify's age and lack of
> committers and Lift's usage scenarios are probably good reasons why the
> respective projects' resources are not spent on fixing this.
> Dan
> On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <njbartlett@gmail.com> wrote:
>> So, they give you API to start a bunch of threads, but not stop them?
>> Awesome...
>> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <dan@elstensoftware.com>
>> wrote:
>>> In one case (JNotify) I create straight wrappers so the JARs are
>>> 'OSGi-ified', in another case I have the JARs embedded in the bundle that
>>> uses them (Lift).
>>> Adding the bundle activator might work if the support to shutdown the
>>> threads is in the API for the code I am using. However, it isn't, and as
>>> you know Java threads are co-operative so I can't simply stop them.
>>> Dan
>>> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fmeschbe@adobe.com
>>> wrote:
>>>> Hi Dan,
>>>> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>>>>>> With respect to when the thread has to stop, think about it the other
>>>>>> way around... what if you never stop any threads? This would mean
>> that
>>>>>> objects allocated by the thread do not become candidates for garbage
>>>>>> collection; therefore neither do the classes that define those
>>>>>> objects; therefore, neither do the classloaders that loaded those
>>>>>> classes. So you're going to create a lot of garbage on the heap,
>>>>>> eventually resulting in OOME. Also, if a bundle's thread continues
>>>>>> running after the bundle has been stopped/updated then you could
>>>>>> unexpected exceptions occurring in that thread; e.g. the bundle
>>>>>> classloader might not allow any new classes to be loaded, and calls
>>>>>> into OSGi using your BundleContext will probably throw
>>>>>> IllegalStateException. Generally these exceptions are not harmful
>>>>>> since you wanted the thread to die anyway, but they could cause
>>>>>> confusion if written to a log.
>>>>> Just to be clear: you're preaching to the converted, I understand why
>> the
>>>>> threads should be stopped. The issue is that I am re-using other
>> projects
>>>>> that don't conform to these rules.... projects that were never
>> written as
>>>>> OSGi bundles. It's a bit like the class loading assumptions you see in
>>>>> other projects... except arguably more subtle.
>>>> So you are using libraries which are not built with OSGi in mind. Still
>>>> you need OSGi manifests for the libraries to become bundles. So you at
>>>> least wrap the libraries somehow to generate the manifest.
>>>> How about adding a BundleActivator as part of this manifest generation ?
>>>> That BundleActivator could in the stop method stop any running threads.
>> The
>>>> BundleActivator is part of the bundle so it may be aware of the library
>>>> internals and be able to stop any running threads.
>>>> Regards
>>>> Felix
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org

Ferry Huberts

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message