Re: Question about current ThreadPool implementation (1.0.7)

[Maki Watanabe <wa...@gmail.com>]

Thanks. I understood the policy.

2012/3/1 Jonathan Ellis <jb...@gmail.com>:
> Right.  We explicitly manage overload by dropping tasks that won't
> complete in time, in OutboundTcpConnection and MessagedDeliveryTask.
>
> On Wed, Feb 29, 2012 at 6:01 AM, Maki Watanabe <wa...@gmail.com> wrote:
>> I've found all JMXEnabledThreadPool and JMXConfigurableThreadPool are
>> constructed with LinkedBlockingQueue as workQueue, and the LBQs are
>> constructed by the default constructor. It means the queue has
>> Integer.MAX_VALUE capacity.
>> In other words, any tasks won't be rejected (Dropped) before we would
>> have Integer.MAX_VALUE=2Billion "Pending" tasks.
>> And even if a task is rejected, DebuggableTheadPool will retry to
>> queue it again in 1000ms interval forever.
>> So, once a runnable task is executed by one of these
>> ThreadPoolExecutor sub classes, it will not be removed nor canceled
>> without the completion (or OOM).
>>
>> Would you confirm my understanding is correct?
>>
>> regards,
>> maki
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com



-- 
w3m