Retries

RxLoadBalancer offers a simple API that defers retry logic to the user. The user can implement any type of complex retry policy using Rx's retry operations such as retry() or onExecptionResumeNext()

Simple retry

The following example shows how to retry a failed operations, regardless of error type.

loadBalancer.select()
   .concatMap(operation)
   .retry(2)
   .single()
   .subscribe(result);

Simple retry with failover on empty load balancer

Swapping the position of single() and retry() will ensure that retries also happen when the load balancer is empty.

loadBalancer.select()
   .concatMap(operation)
   .single()
   .retry(2)
   .subscribe(result);

Exception specific retries

In most real world applications there is a distinction between retryable exceptions, such as timeouts, and non-retryable exceptions, such as invalid requests.

loadBalancer.select()
   .concateMap(operation)
   .retry((t : throwable, n : retry) -> {
       // maximum of 2 retries
       if (n <= 2) return true;
       // retry only on SocketTimeoutException
       if (t instanceof SocketTimeoutException) return true;
       return false;
   })
   .subscribe(result);

Retry multiple times on the same server

There are some use cases where it is desirable to retry an operation on the same server. The following example shows how to retry once on the same server and switch to the next server returned by the load balancer. Note that the second server will be retried once as well.

loadBalancer.select()
   .concatMap((c : Client) => {
        return Observable.just(c)
           .concatMap(operation)
           .retry(1);
   })
   .single();
   .retry(1);

Retry with backoff

• Policy to determine which exception is retryable : Throwble -> Boolean
• Retry on same server
• Retry on 'next' server
• Retry with backoff