dholmes at dltech.com.au
Thu Oct 6 18:57:00 EDT 2005
> Just a little surprising is all, though I'm not sure how the
> ThreadPoolExecutor could know that a queue is non-synchronous?
A check of BlockingQueue.remainingCapacity would tell whether the queue was
bounded or not - but it would be subjective as to how big a value
"unbounded" really is.
> Actually isn't corePoolSize==0 an invalid usage pattern if the queue has
> *any* capacity at all?
With an infinite queue, or a queue you don't expect to fill then it is a
problem. However, you could use a zero core size and a small queue to
effectively "batch" tasks.
ThreadPoolExecutor is quite flexible but a side effect of that is that some
combinations of options make little or no sense.
> What we have is lots of threads active at a time doing things like
> waiting for a database or network response so our pools need to be
> pretty big to accommodate all these IO blocking calls. I'd love to move
> to an event driven non-blocking IO model but unfortunately key
> technologies such as JDBC don't provide any such options.
I see. At this stage "fixing" the pool is probably a better option than
redesigning the core application architecture.
> I'll just maintain a modified version for myself (and anyone else if
> interested, just let me know).
I'm intrigued enough to try and implement that dual queue set up. :)
More information about the Concurrency-interest