[concurrency-interest] ScheduledThreadPoolExecutor woes

Bela Ban belaban at yahoo.com
Tue Jan 23 03:11:54 EST 2007

Thanks for the link Tim,

I looked at it, and while this is close to what I want, it has slightly 
different semantics:

- The retry policy is only invoked when an exception is thrown in 
run()/call(). I would like the retry policy to be invoked after *every* 
- The retry policy *waits* (nanoSleep()) for the next interval. I think 
this is bad as it blocks 1 thread from the thread pool. I'd rather see 
the task being rescheduled: removed from the DelayQueue and reinserted 
into it. This way, we wouldn't need to block a thread

I've tried to extend ScheduledThreadPoolExecutor to do what I want, but 
it being full of private final methods/classes, this is almost 
impossible. I might end up writing my own ScheduledThreadPoolExecutor on 
top of ThreadPoolExecutor... Sigh...

Tim Peierls wrote:
> Last spring Josh Bloch proposed an interface and some standard 
> implementations to capture something like what Bela described.
> public interface RetryPolicy {
>     boolean isFailureRecoverable(Exception e);
>     long nextDelay(long startTime, int retries);
> }
> The implementations included exponential backoff, truncated 
> exponential backoff, and fixed delay.
> There was also a factory method for an ExecutorService wrapper to wrap 
> Runnables and Callables with the machinery needed to implement a given 
> RetryPolicy.
> The idea is that a task signals that it may be retried by throwing an 
> exception e for which RetryPolicy.isFailureRecoverable(e) is true, and 
> the nextDelay method decides, based on the start time of the initial 
> attempt and the number of retries that have occurred, how long to wait 
> before trying again. A negative return from nextDelay means not to try 
> again, in which case the most recent failure exception is rethrown.
> For example, a policy of incessant retrying would be expressed by:
> class IncessantRetrying implements RetryPolicy {
>     public boolean isFailureRecoverable(Exception e) { return true; }
>     long nextDelay(long startTime, int retries) { return 0; }
> }
> Josh told me he'd be willing to distribute this more widely if there 
> was sufficient interest.
> I've placed an incomplete draft of this code in a public area of the 
> Java Concurrency in Practice source repository:
> https://dev.priorartisans.com/repos/jcip/trunk/src/main/jcip/retry/
> It's incomplete because it doesn't define AbstractRetryPolicy.
> What Bela describes is slightly different: each task can be submitted 
> with its own "RetryPolicy". That could be achieved within Josh's 
> framework, for example, by extending ScheduledThreadPoolExecutor and 
> overriding decorateTask to do the requisite wrapping for tasks that 
> implement RetryPolicy.
> --tim

Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat

More information about the Concurrency-interest mailing list