Framework Threads

[Felix Meschberger <Fe...@day.com>]

Hi all,

In a comment to issue FELIX-314 (
https://issues.apache.org/jira/browse/FELIX-314), Karl notes that we should
try to minimize the framework created threads to help in resource critical
environments. Looking at the threads started, I know of the following:

   + PackageAdmin - One thread per framework (Felix) instance
   + EventDispatcher - One thread per class loader hierarchy, shared by
potentially multiple framework instances
   + StartLevel - One thread per framework instances
   + SystemBundle - One thread created to asynchronously stop the framework
   + Config Admin - One thread per framework instance (to dispatch
configuration)
   + Declarative Services - One thread per framework instance (to
enable/disable components)
   + EventAdmin - Thread Pool of configurable size per framework instance

I wonder, whether it would be worth it to have a general "task dispatching"
facility, which would manage the threads. Or have the threads to be separate
such that for example asynchronous EventDispatcher events are not postponed
until an eventual StartLevel change has finished ?

This is just a quick idea off the top of my head and I only have a very
vague idea of how to implement it...

Regards
Felix

Re: Framework Threads

["Richard S. Hall" <he...@ungoverned.org>]

Felix Meschberger wrote:
>   + PackageAdmin - One thread per framework (Felix) instance

This was the main other culprit I was thinking about and clearly it 
doesn't have enough activity to keep itself busy, so it might be a good 
candidate for sharing if possible to do it cleanly.

>   + EventDispatcher - One thread per class loader hierarchy, shared by
> potentially multiple framework instances
>   + StartLevel - One thread per framework instances

This one should be investigated too.

>   + SystemBundle - One thread created to asynchronously stop the 
> framework

This one is not an issue since the thread just lives transiently to stop 
the framework instance.

>   + Config Admin - One thread per framework instance (to dispatch
> configuration)
>   + Declarative Services - One thread per framework instance (to
> enable/disable components)
>   + EventAdmin - Thread Pool of configurable size per framework instance

I am not so concerned about bundles, but it is also possible for us to 
consider some sort of thread pool service for them.

> I wonder, whether it would be worth it to have a general "task 
> dispatching"
> facility, which would manage the threads. Or have the threads to be 
> separate
> such that for example asynchronous EventDispatcher events are not 
> postponed
> until an eventual StartLevel change has finished ?

Yeah, I don't think we want to go too crazy. I think it makes sense to 
try to aggregate threads a little, but we don't want to over do it.

> This is just a quick idea off the top of my head and I only have a very
> vague idea of how to implement it...

For me, the important ones are the ones used by the framework. For the 
framework, we could consider some sort of Thread Pool/Task manager...it 
seems like a do-able task. However, the secondary goal for the framework 
is to stay simple, so I would only be in favor of it if it didn't add 
any bloat. Could be interesting to investigate though.

-> richard