Amen. This is exactly what we have learned in GigaSpaces when had to address these Jini lock contention issues long time ago.
Shay ----- Original Message ----- From: Gregg Wonderly <[email protected]> To: [email protected] <[email protected]> Sent: Fri Jun 04 13:11:15 2010 Subject: Re: com.sun.jini.thread lock contention I'd have to say no for the existing Executor implementations in the JDK. The concurrency utilities related to Executor in the JDK are tailored for, and specifically limited to applications where you have unrelated tasks that need to be throttled amongst a limited set of threads. River's TaskManager will always create more threads, but will prune those threads after they sit idle for too long. We need this behavior to keep away from distributed deadlock which can occur anytime another remote operation might be the only way that progress can happen in the overall processing of a distributed application. Be very careful where you use j.u.c ThreadPoolExecutor et.al, because of their design. It would be possible to use an appropriate Executor implementation, but it would have to behave like TaskManager and always create a new thread for new work, when no idle threads are available. Gregg Wonderly Dennis Reedy wrote: > Hi Gregg, > > Does it make sense to move to concurrency utilities and move away from > TaskManager altogether? > > Dennis > > On Jun 4, 2010, at 1100AM, Gregg Wonderly wrote: > >> The TaskManager class has a subclass of Thread that it uses to run tasks. >> The problem with subclassing Thread, is that there is a lock that is used in >> Thread to see if some methods are overridden so that security can be >> maintained. So, in an environment where Thread is used with a >> SecurityManager, it is better to use a Runnable to encapsulate the custom >> code, instead of a Thread. >> >> The TaskThread class should be a Runnable instead of a Thread, and then >> there are just 3 other places where it is referenced that need some >> adjustment. The thread that is running inside of the runnable needs to be >> put into a per instance variable for one place where interrupt processing is >> handled. >> >> Gregg Wonderly > >
