public class ThreadLocalRetryLoop extends Object
Retry loops can easily end up getting nested which can cause exponential calls of the retry policy (see https://issues.apache.org/jira/browse/CURATOR-559). This utility works around that by using an internal ThreadLocal to hold a retry loop. E.g. if the retry loop fails anywhere in the chain of nested calls it will fail for the rest of the nested calls instead.
Example usage:
ThreadLocalRetryLoop threadLocalRetryLoop = new ThreadLocalRetryLoop();
RetryLoop retryLoop = threadLocalRetryLoop.getRetryLoop(client::newRetryLoop);
try
{
while ( retryLoop.shouldContinue() )
{
try
{
// do work
retryLoop.markComplete();
}
catch ( Exception e )
{
ThreadUtils.checkInterrupted(e);
retryLoop.takeException(e);
}
}
}
finally
{
threadLocalRetryLoop.release();
}
Constructor and Description |
---|
ThreadLocalRetryLoop() |
Modifier and Type | Method and Description |
---|---|
RetryLoop |
getRetryLoop(Supplier<RetryLoop> newRetryLoopSupplier)
Call to get the current retry loop.
|
void |
release()
Must be called to release the retry loop.
|
public RetryLoop getRetryLoop(Supplier<RetryLoop> newRetryLoopSupplier)
newRetryLoopSupplier
.newRetryLoopSupplier
- supply a new retry loop when needed. Normally you should use CuratorZookeeperClient.newRetryLoop()
public void release()
RetryLoop.callWithRetry(org.apache.curator.CuratorZookeeperClient, java.util.concurrent.Callable)
for an example usage.Copyright © 2011–2023 The Apache Software Foundation. All rights reserved.