Thanks. I understood the policy. 2012/3/1 Jonathan Ellis <jbel...@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 <watanabe.m...@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
