Creating new threads in sling code

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating new threads in sling code

Jörg Hoh
Hi,

It already fell a number of times over code in sling, where threads are
created manually like this:

Thread t = new Thread(someRunnable);
t.start();

I understand, that this is convenient and solves the problem in most of the
cases. But I see these problems:

* In most cases noone takes care if these threads terminate at all; they
just run in an uncontrolled manner and terminate by chance. If these
threads are not started exactly once, but possible multiple times (even in
parallel), the system could get in a state, where a huge amount of these
threads are running concurrently (and noone notices it!).
* These threads do not use a threadpool and therefor they cannot be limited.
* The J2E programming model discourages the creation of threads; instead
one is supposed to use the threadpools of the application server. This is
important in appservers like Websphere AS, where the succesfull lookup of
JNDI resources is directly bound to the fact, that the thread, which tries
it, comes from a Websphere threadpool.

I propose, that we avoid to create threads like above and  use a sling
default threadpool instance. This threadpool creates the threads by itself
by default; for appservers we could implement specific fragment bundles,
which uses the pools provided by the appserver.

This could solve the problems of threads being created in an uncontrolled
fashion, and also solves some problems regarding the integration of J2E
apps into Sling.


WDYT?


Jörg
Reply | Threaded
Open this post in threaded view
|

Re: Creating new threads in sling code

Felix Meschberger-3
Hi

> Am 08.12.2014 um 12:41 schrieb Jörg Hoh <[hidden email]>:
>
> Hi,
>
> It already fell a number of times over code in sling, where threads are
> created manually like this:
>
> Thread t = new Thread(someRunnable);
> t.start();
>
> I understand, that this is convenient and solves the problem in most of the
> cases. But I see these problems:
>
> * In most cases noone takes care if these threads terminate at all; they
> just run in an uncontrolled manner and terminate by chance. If these
> threads are not started exactly once, but possible multiple times (even in
> parallel), the system could get in a state, where a huge amount of these
> threads are running concurrently (and noone notices it!).

I would think that these cases are just bugs. Would be great if you could report issues.

IIRC most of the times I did create threads, I took care to only run one and make sure the thread also terminates.

> * These threads do not use a threadpool and therefor they cannot be limited.

Its hard to come up with limitations if a single component just wants to launch a single thread for some specific processing. If such a component hits the thread pool limit, you actually prevent the component from operating properly.


> * The J2E programming model discourages the creation of threads; instead
> one is supposed to use the threadpools of the application server. This is
> important in appservers like Websphere AS, where the succesfull lookup of
> JNDI resources is directly bound to the fact, that the thread, which tries
> it, comes from a Websphere thread pool.

Yes, that *is* a problem. And I am not sure whether we can easily solve this. Except by not deploying as a web application. For example in WebSphere with Liberty Profile, Sling could be deployed directly into WebSphere’s OSGi framework and thus directly access the JNDI resources through the OSGi JNDI service.

Interestingly the actual problem of reading JNDI resources during startup — looking up a JNDI DataSource to be used for an Oak Microkernel - is harder to solve: This thread is the Felix Framework Startlevel service thread which is also created with new Thread and not with some thread pooling.

(Yet, it is important to note, that the framework is not able to start if the Startlevel thread could not be retrieved)

>
> I propose, that we avoid to create threads like above and  use a sling
> default threadpool instance. This threadpool creates the threads by itself
> by default; for appservers we could implement specific fragment bundles,
> which uses the pools provided by the appserver.
>
> This could solve the problems of threads being created in an uncontrolled
> fashion, and also solves some problems regarding the integration of J2E
> apps into Sling.
>
>
> WDYT?

I think it basically is an ok idea, which we might want to follow-up upon. Yet, we would not fully solve the problem, since some of the threads created are outside of the control of Sling, particularly the Startlevel thread used by the framework.

Yet, there’s JSR 236 (Concurrency Utilities for J2EE). Maybe we should look into this ? Unfortunately its only part of J2EE 7 so your favourite blend of App Server might not actually support it.

Regards
Felix
Reply | Threaded
Open this post in threaded view
|

Re: Creating new threads in sling code

Carsten Ziegeler
Am 08.12.14 um 14:34 schrieb Felix Meschberger:

> Hi
>
>> Am 08.12.2014 um 12:41 schrieb Jörg Hoh <[hidden email]>:
>>
>> * In most cases noone takes care if these threads terminate at all; they
>> just run in an uncontrolled manner and terminate by chance. If these
>> threads are not started exactly once, but possible multiple times (even in
>> parallel), the system could get in a state, where a huge amount of these
>> threads are running concurrently (and noone notices it!).
>
> I would think that these cases are just bugs. Would be great if you could report issues.
>
> IIRC most of the times I did create threads, I took care to only run one and make sure the thread also terminates.

Yepp, I agree. If we have such code this more sounds like a bug to me,
especially as we have a thread pool service in Sling :)

>
>> * These threads do not use a threadpool and therefor they cannot be limited.
>
> Its hard to come up with limitations if a single component just wants to launch a single thread for some specific processing. If such a component hits the thread pool limit, you actually prevent the component from operating properly.

Exactly, there are valid use cases for not using a limiting thread pool.

Carsten

>
>
>> * The J2E programming model discourages the creation of threads; instead
>> one is supposed to use the threadpools of the application server. This is
>> important in appservers like Websphere AS, where the succesfull lookup of
>> JNDI resources is directly bound to the fact, that the thread, which tries
>> it, comes from a Websphere thread pool.
>
> Yes, that *is* a problem. And I am not sure whether we can easily solve this. Except by not deploying as a web application. For example in WebSphere with Liberty Profile, Sling could be deployed directly into WebSphere’s OSGi framework and thus directly access the JNDI resources through the OSGi JNDI service.
>
> Interestingly the actual problem of reading JNDI resources during startup — looking up a JNDI DataSource to be used for an Oak Microkernel - is harder to solve: This thread is the Felix Framework Startlevel service thread which is also created with new Thread and not with some thread pooling.
>
> (Yet, it is important to note, that the framework is not able to start if the Startlevel thread could not be retrieved)
>
>>
>> I propose, that we avoid to create threads like above and  use a sling
>> default threadpool instance. This threadpool creates the threads by itself
>> by default; for appservers we could implement specific fragment bundles,
>> which uses the pools provided by the appserver.
>>
>> This could solve the problems of threads being created in an uncontrolled
>> fashion, and also solves some problems regarding the integration of J2E
>> apps into Sling.
>>
>>
>> WDYT?
>
> I think it basically is an ok idea, which we might want to follow-up upon. Yet, we would not fully solve the problem, since some of the threads created are outside of the control of Sling, particularly the Startlevel thread used by the framework.
>
> Yet, there’s JSR 236 (Concurrency Utilities for J2EE). Maybe we should look into this ? Unfortunately its only part of J2EE 7 so your favourite blend of App Server might not actually support it.
>
> Regards
> Felix
>


--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Creating new threads in sling code

Jörg Hoh
In reply to this post by Felix Meschberger-3
Hi Felix

2014-12-08 14:34 GMT+01:00 Felix Meschberger <[hidden email]>:



>
>
> > * The J2E programming model discourages the creation of threads; instead
> > one is supposed to use the threadpools of the application server. This is
> > important in appservers like Websphere AS, where the succesfull lookup of
> > JNDI resources is directly bound to the fact, that the thread, which
> tries
> > it, comes from a Websphere thread pool.
>
> Yes, that *is* a problem. And I am not sure whether we can easily solve
> this. Except by not deploying as a web application. For example in
> WebSphere with Liberty Profile, Sling could be deployed directly into
> WebSphere’s OSGi framework and thus directly access the JNDI resources
> through the OSGi JNDI service.
>


And that's the problem I have, and the reason for my proposal :-)


>
> Interestingly the actual problem of reading JNDI resources during startup
> — looking up a JNDI DataSource to be used for an Oak Microkernel - is
> harder to solve: This thread is the Felix Framework Startlevel service
> thread which is also created with new Thread and not with some thread
> pooling.
>
> (Yet, it is important to note, that the framework is not able to start if
> the Startlevel thread could not be retrieved)
>

Hm, if we're talking about about appservers support: in the launchpad we
also create a number of threads; most specifically the Sling Notifier
thread and the OSGI Installer thread. Both of them are involved in the
startup of the bundles and services.


> WDYT?
>
> I think it basically is an ok idea, which we might want to follow-up upon.
> Yet, we would not fully solve the problem, since some of the threads
> created are outside of the control of Sling, particularly the Startlevel
> thread used by the framework.
>

For the moment I would be happy, if we could migrate the threads created by
Sling. The Felix threads are a different story.



>
> Yet, there’s JSR 236 (Concurrency Utilities for J2EE). Maybe we should
> look into this ? Unfortunately its only part of J2EE 7 so your favourite
> blend of App Server might not actually support it.
>

"favourite blend of App servers" ... You owe me a beer now :-)

Can we split the application specific parts into own bundles and provide a
JSR236 compliant code, plus a simple version with its own threadpool.



--
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh
Reply | Threaded
Open this post in threaded view
|

Re: Creating new threads in sling code

Felix Meschberger-3
Hi Jörg

> Am 08.12.2014 um 22:31 schrieb Jörg Hoh <[hidden email]>:
>
> Hi Felix
>
> 2014-12-08 14:34 GMT+01:00 Felix Meschberger <[hidden email]>:
>
>
>
>>
>>
>>> * The J2E programming model discourages the creation of threads; instead
>>> one is supposed to use the threadpools of the application server. This is
>>> important in appservers like Websphere AS, where the succesfull lookup of
>>> JNDI resources is directly bound to the fact, that the thread, which
>> tries
>>> it, comes from a Websphere thread pool.
>>
>> Yes, that *is* a problem. And I am not sure whether we can easily solve
>> this. Except by not deploying as a web application. For example in
>> WebSphere with Liberty Profile, Sling could be deployed directly into
>> WebSphere’s OSGi framework and thus directly access the JNDI resources
>> through the OSGi JNDI service.
>>
>
>
> And that's the problem I have, and the reason for my proposal :-)
>
>
>>
>> Interestingly the actual problem of reading JNDI resources during startup
>> — looking up a JNDI DataSource to be used for an Oak Microkernel - is
>> harder to solve: This thread is the Felix Framework Startlevel service
>> thread which is also created with new Thread and not with some thread
>> pooling.
>>
>> (Yet, it is important to note, that the framework is not able to start if
>> the Startlevel thread could not be retrieved)
>>
>
> Hm, if we're talking about about appservers support: in the launchpad we
> also create a number of threads; most specifically the Sling Notifier
> thread and the OSGI Installer thread. Both of them are involved in the
> startup of the bundles and services.
>
>
>> WDYT?
>>
>> I think it basically is an ok idea, which we might want to follow-up upon.
>> Yet, we would not fully solve the problem, since some of the threads
>> created are outside of the control of Sling, particularly the Startlevel
>> thread used by the framework.
>>
>
> For the moment I would be happy, if we could migrate the threads created by
> Sling. The Felix threads are a different story.

Sure,  but an essential one. Just solving the OSGi Installer, for example, does not solve the problem on restart …

>
>
>
>>
>> Yet, there’s JSR 236 (Concurrency Utilities for J2EE). Maybe we should
>> look into this ? Unfortunately its only part of J2EE 7 so your favourite
>> blend of App Server might not actually support it.
>>
>
> "favourite blend of App servers" ... You owe me a beer now :-)
>
> Can we split the application specific parts into own bundles and provide a
> JSR236 compliant code, plus a simple version with its own thread pool.

Maybe we should be retrofitting our ThreadPool support to JSR-236. But, as I said, in a App Server context can you use JSR-236 ? Does WebSphere 7.x provide ? Do they have IBM specific API ? What API ? Which app servers is Sling going to support ?

Regards
Felix

>
>
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh

Reply | Threaded
Open this post in threaded view
|

Re: Creating new threads in sling code

Michael Dürig-3
In reply to this post by Jörg Hoh

Hi,

IMO clients should not get in touch with threads at all. Not even
through thread pools. Instead the framework should provide means to
execute and schedule concurrent (background) tasks. In general the
framework is in a much better position to decide whether such an
execution is worth an other thread or could be executed by other means.

Threads are a very low level concept and as with automatic memory
management (e.g. GC) its management should be best left to the framework
/ execution environment. After all the execution environment knows best
about available resources (e.g. CPU cores), system load, etc.

Sling makes some initial effort towards this through its
ThreadPoolManager. Unfortunately this uses Java Futures, which are
severely broken. The upcoming OSGI Asynchronous Services specification
might be a better fit here.

Michael

On 8.12.14 12:41 , Jörg Hoh wrote:

> Hi,
>
> It already fell a number of times over code in sling, where threads are
> created manually like this:
>
> Thread t = new Thread(someRunnable);
> t.start();
>
> I understand, that this is convenient and solves the problem in most of the
> cases. But I see these problems:
>
> * In most cases noone takes care if these threads terminate at all; they
> just run in an uncontrolled manner and terminate by chance. If these
> threads are not started exactly once, but possible multiple times (even in
> parallel), the system could get in a state, where a huge amount of these
> threads are running concurrently (and noone notices it!).
> * These threads do not use a threadpool and therefor they cannot be limited.
> * The J2E programming model discourages the creation of threads; instead
> one is supposed to use the threadpools of the application server. This is
> important in appservers like Websphere AS, where the succesfull lookup of
> JNDI resources is directly bound to the fact, that the thread, which tries
> it, comes from a Websphere threadpool.
>
> I propose, that we avoid to create threads like above and  use a sling
> default threadpool instance. This threadpool creates the threads by itself
> by default; for appservers we could implement specific fragment bundles,
> which uses the pools provided by the appserver.
>
> This could solve the problems of threads being created in an uncontrolled
> fashion, and also solves some problems regarding the integration of J2E
> apps into Sling.
>
>
> WDYT?
>
>
> Jörg
>