Am 08.12.14 um 14:34 schrieb Felix Meschberger: > Hi > >> Am 08.12.2014 um 12:41 schrieb Jörg Hoh <jhoh...@googlemail.com>: >> >> * 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 cziege...@apache.org
