river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: com.sun.jini.thread lock contention
Date Sat, 05 Jun 2010 10:47:54 GMT
Gregg,

Thanks for sharing these nuggets of wisdom.

Peter.


Shay Hassidim wrote:
> 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 <gregg@wonderly.org>
> To: river-dev@incubator.apache.org <river-dev@incubator.apache.org>
> 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
>>>       
>>     
>
>
>
>
>   


Mime
View raw message