[concurrency-interest] LIFO ThreadPoolExecutor

Joe Bowbeer joe.bowbeer at gmail.com
Tue Apr 28 17:03:05 EDT 2009

This is a complex question and I'm unable to answer it directly.

I do suggest you consider a couple alternatives:

1. CallerRunsPolicy with bounded queue and core & max threads.

Rather than rejecting a new request, this will service it in the calling
thread.  When heavily loaded, this policy throttles demand and tends to
devote more resources to newer requests.

2. DiscardOldestPolicy with bounded queue and core & max threads.

This will discard the oldest request before rejecting a new request.  With
luck, the discarded requests will no longer be relevant.  If your service is
"leaky" (that is, if it is allowed to punt when it is overloaded), this may
be a good option.

If your bounded queue is really a bounded stack, then a DiscardBottomPolicy
might work really well.  This would service requests in LIFO order until it
is swamped, and then discard the oldest requests.

Btw, I suspect the ScalingQueue implementation has a problem or two at the
corner cases, but this is only a suspicion.


On Tue, Apr 28, 2009 at 12:43 PM, Paulo Levi wrote:

> I'm doing requests to a web service for thumbnails over a
> threadpoolexecutor, configured like this:
> http://www.kimchy.org/juc-executorservice-gotcha/
> As I'm using a web service I'd like to configure the Linked blocking queue
> the executors use to be able to be LIFO (according to the factory method),
> so that the relevant requests are processed first. [...]
> I'm asking the way to modify LinkedBlockingQueue and SynchronousQueue so
> that i can implement LIFO for the ThreadPoolExecutor.
> I know this is a complex question - but i'm really raw at implementing data
> structures like this, and i fear screwing it up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090428/bbe305b5/attachment.html>

More information about the Concurrency-interest mailing list