incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Question about current ThreadPool implementation (1.0.7)
Date Wed, 29 Feb 2012 16:11:48 GMT
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 <watanabe.maki@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

Mime
View raw message