You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/10/03 11:44:36 UTC

OSGi bundle

Hello Chris and all

Thanks for the feedback on MessageFormat!

Next topic: we are suppose to be OSGi-ready, but I actually have no 
experience in that aspect. From what I have read, we must ensure that 
all threads created by a module must be terminated when the bundle stop.

I committed a Threads class (not part of public API) in 
org.apache.sis.internal, which we can use for keeping trace of all 
threads created by the library (only one in the "sis-utility" module). I 
used it in the past for grouping the library threads under a single 
ThreadGroup, which is quite helpful when inspecting the threads in a 
debugger. In a pure JSEE environment, we just let the daemon threads die 
on JVM exit. But in an OSGi environment, my understanding is that we 
shall terminate those threads explicitly. I added an OSGiActivator class 
for that purpose (implements BundleActivator, declared in the 
MANIFEST.MF file). Is there other aspects that I should be aware of (I 
know there is also ThreadLocal variables to be careful with)?

     Thanks,

         Martin




Le 02/10/12 16:21, Mattmann, Chris A (388J) a écrit :
> +1 for MessageFormat, for the exact reasons you specify below (err on the side of
> readability and understandability).

Re: OSGi bundle

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,

Thanks for clearing that up makes total sense!

Cheers,
Chris

On Oct 4, 2012, at 9:52 AM, Martin Desruisseaux wrote:

> Hello Chris
> 
> Le 05/10/12 00:10, Mattmann, Chris A (388J) a écrit :
>> Thanks for taking care of this work and I saw the Threads classes you've
>> been working on. I have a question -- how do these relate to the java.util.concurrent
>> packages -- are those incompatible with OSGI giving us a need to construct our own
>> such classes in SIS, or are the classes you are committing complementary and/or
>> orthogonal to java.util.concurrent?
> 
> java.util.concurrent is not incompatible with OSGi as far as I know. Actually I use and like this package, but the DaemonThread committed yesterday is for a different purpose.
> 
> java.util.concurrent provides Executors which receive tasks, pick some available threads in a ThreadPool (creating new ones if needed), uses the thread for executing the task until completion, then give back the thread to the ThreadPool. The new fork-join framework in JDK7 goes on step further by transferring some piece of work from one thread to an other. Each task uses a thread for a limited amount of time.
> 
> The class that I committed is a single daemon thread living for the whole application lifetime. There is no ThreadPool. The thread is dedicated to a single job: to watch a ReferenceQueue for doing cleaning work when some objects are garbage collected. We do not submit tasks ourselves; on the contrary, we wait for tasks to come from the garbage collector. So this is the opposite of a java.util.concurrent.Executor :)
> 
> I plan to use java.util.concurrent for tasks that are more computational (I already do in Geotk).
> 
> Thanks for your feedback,
> 
>    Martin
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: OSGi bundle

Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris

Le 05/10/12 00:10, Mattmann, Chris A (388J) a écrit :
> Thanks for taking care of this work and I saw the Threads classes you've
> been working on. I have a question -- how do these relate to the java.util.concurrent
> packages -- are those incompatible with OSGI giving us a need to construct our own
> such classes in SIS, or are the classes you are committing complementary and/or
> orthogonal to java.util.concurrent?

java.util.concurrent is not incompatible with OSGi as far as I know. 
Actually I use and like this package, but the DaemonThread committed 
yesterday is for a different purpose.

java.util.concurrent provides Executors which receive tasks, pick some 
available threads in a ThreadPool (creating new ones if needed), uses 
the thread for executing the task until completion, then give back the 
thread to the ThreadPool. The new fork-join framework in JDK7 goes on 
step further by transferring some piece of work from one thread to an 
other. Each task uses a thread for a limited amount of time.

The class that I committed is a single daemon thread living for the 
whole application lifetime. There is no ThreadPool. The thread is 
dedicated to a single job: to watch a ReferenceQueue for doing cleaning 
work when some objects are garbage collected. We do not submit tasks 
ourselves; on the contrary, we wait for tasks to come from the garbage 
collector. So this is the opposite of a java.util.concurrent.Executor :)

I plan to use java.util.concurrent for tasks that are more computational 
(I already do in Geotk).

Thanks for your feedback,

     Martin

Re: OSGi bundle

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,

Thanks for taking care of this work and I saw the Threads classes you've
been working on. I have a question -- how do these relate to the java.util.concurrent
packages -- are those incompatible with OSGI giving us a need to construct our own
such classes in SIS, or are the classes you are committing complementary and/or 
orthogonal to java.util.concurrent?

Thanks!

Cheers,
Chris

On Oct 3, 2012, at 2:44 AM, Martin Desruisseaux wrote:

> Hello Chris and all
> 
> Thanks for the feedback on MessageFormat!
> 
> Next topic: we are suppose to be OSGi-ready, but I actually have no experience in that aspect. From what I have read, we must ensure that all threads created by a module must be terminated when the bundle stop.
> 
> I committed a Threads class (not part of public API) in org.apache.sis.internal, which we can use for keeping trace of all threads created by the library (only one in the "sis-utility" module). I used it in the past for grouping the library threads under a single ThreadGroup, which is quite helpful when inspecting the threads in a debugger. In a pure JSEE environment, we just let the daemon threads die on JVM exit. But in an OSGi environment, my understanding is that we shall terminate those threads explicitly. I added an OSGiActivator class for that purpose (implements BundleActivator, declared in the MANIFEST.MF file). Is there other aspects that I should be aware of (I know there is also ThreadLocal variables to be careful with)?
> 
>    Thanks,
> 
>        Martin
> 
> 
> 
> 
> Le 02/10/12 16:21, Mattmann, Chris A (388J) a écrit :
>> +1 for MessageFormat, for the exact reasons you specify below (err on the side of
>> readability and understandability).
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++