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
