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
