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
