Hi > Am 08.12.2014 um 12:41 schrieb Jörg Hoh <[email protected]>: > > 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
