You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Per-Erik Svensson <pe...@gmail.com> on 2011/01/21 00:02:28 UTC
Question regarding time of class loading and OSGi-threading tips
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.
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.
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? :)
Ok, (d) would it help writing "MyClass.class.getName()"?
Regards,
Per-Erik Svensson
Re: Question regarding time of class loading and OSGi-threading tips
Posted by Per-Erik Svensson <pe...@gmail.com>.
Thanks for the answers!
Regards,
Per-Erik Svensson
On Fri, Jan 21, 2011 at 4:35 PM, Richard S. Hall <he...@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
>
>
Re: Question regarding time of class loading and OSGi-threading tips
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<he...@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
Re: Question regarding time of class loading and OSGi-threading tips
Posted by Per-Erik Svensson <pe...@gmail.com>.
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?
Regards,
Per-Erik Svensson
On Fri, Jan 21, 2011 at 1:57 AM, Richard S. Hall <he...@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
>
>
Re: Question regarding time of class loading and OSGi-threading tips
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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