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.

Are your dependencies safe to use?

Using components with known vulnerabilities is the ninth item described by the OWASP top ten and widely ignored item in application security.According to the article "The Unfortunate Reality of Insecure Libraries" most of us are not aware of that, our application contains well-known vulnerabilities.
Follow are some interesting finding of the article.

• 29.8 million (26%) of library downloads have known vulnerabilities
• Security libraries are slightly more likely to have a known vulnerability than frameworks
• Java apps are likely to include at least one vulnerable library
• The most downloaded vulnerable libraries were GWT, Xerces, Spring MVC, and Struts 1.x

So it is really important to inspect our dependencies very frequently against those known issues.
OWASP dependency checker is a tool which is used to identify vulnerabilities in Java. Since it comes with Maven, Gradle, Ant plugins it is really easy for a developer to inspect those vulnerabilities. It also comes as Jenkins plugin so we can easily integrate and check periodically for vulnerabilities without human intervention.

Integrating OWASP Dependency checker for Maven.
Include following plugin in to your plugins section of the POM file.

<plugin>
 <groupId>org.owasp</groupId>
 <artifactId>dependency-check-maven</artifactId>
 <version>2.0.0</version>
 <executions>
    <execution>
                 <goals>
                         <goal>check</goal>
                       </goals>
                 </execution>
        </executions>
</plugin>

Once plugin is configured we can invoke the plugin by executing following maven goal

mvn clean install

It will cross check your dependencies against the vulnerability data base and generate a report if anything suspicious available. But keep in mind there can be false positive results as well.

Example report:

[INFO] Analysis Complete (5 seconds)
[WARNING] 

One or more dependencies were identified with known vulnerabilities 
in prject name:

jar-file-name-1.3.1.jar (jar-file-name:jar-file-name:x.x.x, 
cpe:/a:groupId:artifact_id:x.x.x) : CVE-2020-9999, CVE-2020-4444444


See the dependency-check report for more details.


[INFO]