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
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
Hi
Am 08.12.2014 um 12:41 schrieb Jörg Hoh jhoh...@googlemail.com:
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
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
Hi Felix
2014-12-08 14:34 GMT+01:00 Felix Meschberger fmesc...@adobe.com:
* 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
Hi Jörg
Am 08.12.2014 um 22:31 schrieb Jörg Hoh jhoh...@googlemail.com:
Hi Felix
2014-12-08 14:34 GMT+01:00 Felix Meschberger fmesc...@adobe.com:
* The J2E programming model discourages the creation of threads; instead
one is supposed to use the threadpools of the application
