Are you limiting your rate with Thread Sleep ?

Let me start with two scenarios where you may have encountered before.

Scenario 1: You have an application which connects to a queuing service and suddenly you lose the network connectivity.

Scenario 2: Your application invoking an external API and it starts to reject your calls due to the high rate of access.

If we look at those two, you may think it's really simple to solve those issues by sleeping the thread. For the first scenario, you can define a maximum number of retries and sleep in between each retry. For the second scenario, imposing explicit thread sleep will reduce the rate of your API access.

Let's assume we are checking connectivity each second and assume we got the connectivity by 6.5 seconds. If we use a sequential approach such as thread sleep, we are attempting 7 times to establish a connection.

When re connecting we have to consider two key aspects

1. Limit number of attempts ( each attempt is an overhead to the application)
2. Reconnect should happen as soon as connectivity back to normal.

If we increase the sleep time to reduce the attempts it leads us to violate the second aspect. So it is important to understand that sequential approach is not the best approach for many cases. There are other sequences that may be more suitable for your scenario such as linear, Fibonacci.

Limiting the rate of calls with spring-retry

With spring retry we can try out few different approaches, it can be a linear or Fibonacci or a custom approach.With the latest spring versions you may find this as a feature of the frame work but if you are not using spring or using an older version of spring framework, you can use this library as a dependency.So we are no longer required to use thread sleep as our default wait mechanism as well as we are not required to re invent the wheel when we wanted to try out some other re trying sequence.

Please visit the spring retry git hub project for more information and examples.