felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per-Erik Svensson <pererik.svens...@gmail.com>
Subject Re: Question regarding time of class loading and OSGi-threading tips
Date Fri, 21 Jan 2011 22:02:45 GMT
Thanks for the answers!

Per-Erik Svensson

On Fri, Jan 21, 2011 at 4:35 PM, Richard S. Hall <heavy@ungoverned.org>wrote:

> On 1/21/11 3:29, Per-Erik Svensson wrote:
>> Thanks! All that makes sense, and I guess the problem is that the swing
>> worker switches to its done method (to the edt) when cancelled. I have no
>> good (read easy) way of synchronizing the bundle.stop() with this.
>> But, do I understand you correctly if I say that you can (and should)
>> block
>> inside bundle.stop until all threads have finnished? What happens with
>> Felix's other responsibilities in the mean time? Do all "pending" service
>> requests and bundle events (stopping, starting..) block? What is the
>> thread
>> "rules" when it comes to OSGi?
> Yes, some things will block.
> The rules dictate you should be quick in your stop(), but at the same time
> the rules dictate that your bundle should be stopped after stop() (i.e.,
> your bundle shouldn't be doing stuff on background threads).
> -> richard
>  Regards,
>> Per-Erik Svensson
>> On Fri, Jan 21, 2011 at 1:57 AM, Richard S. Hall<heavy@ungoverned.org
>> >wrote:
>>  On 1/20/11 6:02 PM, Per-Erik Svensson wrote:
>>>  Hi,
>>>> I would like to know when a class is loaded. I guess it is a bit
>>>> different
>>>> depending on things like usage of static members and the like but... Say
>>>> java.util.Logger. I have a bundle that only consumes services. When the
>>>> bundle is started it is running a few background threads. When the
>>>> bundle
>>>> is
>>>> stopped, the background threads are cancelled. When they are cancelled,
>>>> they
>>>> will post a task on the event dispatch thread (I'm using swing workers)
>>>> and,
>>>> since they were cancelled, they will log just that ("Background thread
>>>> interrupted" or similar is written to log).
>>>> Now, everything worked fine up until the edt-task was about to log. At
>>>> that
>>>> point, felix threw an exception. Sadly, I don't have the stack trace atm
>>>> and
>>>> I'm not sure I can reproduce. I'm just curious if anyone knows what this
>>>> can
>>>> be. The offending line was calling
>>>> java.util.Logger.getLogger(getClass().getName()).log(Level.INFO,
>>>> "BG-thread
>>>> cancelled) //or similar
>>>> And remember that the bundle jar-file has been removed (with the help of
>>>> FileInstall) from the system. It might linger in the bundle cache (I
>>>> don't
>>>> know how long it stays there) but the bundle is stopped and (presumably)
>>>> uninstalled.
>>>> I just removed the logger code to make it work. However, I'm suspecting
>>>> that
>>>> the cause of the error is either
>>>>    1. getClass() must have a class loader and that is gone because the
>>>>    bundle is uninstalled.
>>>>  If you have a thread executing on the class, then the class loader
>>> isn't
>>> gone since the thread has a reference to the class and the class has a
>>> reference to its class loader.
>>>     2. The static Logger isn't loaded yet or uses classes that aren't
>>>> loaded
>>>>    yet and thus felix informs me that it cant find the class.
>>>>  Something like this could be.
>>>  So, (a) when is a class loaded, (b) is there any good "pattern" for
>>>> dealing
>>>> with disposing threads in OSGi, and (c) am I completely off here? :)
>>>>  For (a) it just depends. They are loaded on demand by the JVM. In some
>>> cases loading a class will cause other class loads for dependent types
>>> necessary for defining the class. For types used in methods, they will be
>>> loaded on demand (although I'm not sure if this is mandated).
>>> For (b), the best you can do is stop your threads in your activator
>>> stop()
>>> method. Your bundle will not be uninstalled until after it returns from
>>> its
>>> stop() method. In Felix, we don't hold locks for class loading, so you
>>> can
>>> end up with situations were threads will have issues loading classes from
>>> a
>>> dependent bundle, but they won't have problems loading classes from
>>> themselves as long as they are stopped in their activator stop() method.
>>> ->  richard
>>>  Ok, (d) would it help writing "MyClass.class.getName()"?
>>>> Regards,
>>>> Per-Erik Svensson
>>>>  ---------------------------------------------------------------------
>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message