[concurrency-interest] ScheduledThreadPoolExecutor woes

Hanson Char hanson.char at gmail.com
Sat Feb 3 21:12:23 EST 2007


Hi Tim,

>Josh told me he'd be willing to distribute this more widely if there was
sufficient interest.

I am very interested in the retry policy code.

>I've placed an incomplete draft of this code in a public area of the Java
Concurrency in Practice source repository:

Any chance I can find the missing pieces ?

Thanks in advance.

Hanson

On 1/20/07, Tim Peierls <tim at peierls.net> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070203/121d93c1/attachment.html 


More information about the Concurrency-interest mailing list