06. April 2018

3 min

MicroProfile with fault tolerance and configuration

In times of ever changing business requirements, it is very important for Java EE to have the ability to react fast and accurate to those changes. As of now its heavyweight process is a great handicap compared to more lightweight frameworks such as Spring. In this context heavyweight means that the whole process of including new features and releasing new versions of the whole stack takes multiple times (even years!). That’s where MicroProfile, a part of the Eclipse Foundation, comes into play.

But in the past few releases, more and more very useful specifications were included, for example MicroProfile Config and MicroProfile Fault Tolerance. Let’s find out what they are basically good for and how to work with them.

Eclipse MicroProfile config

MicroProfile config is a solution to externalize configuration from microservices. The configuration properties are provided by so called ConfigSources, which are ordered according to their ordinal, with a higher value taking priority over a lower one. For example, in Websphere Liberty this means that if the same configuration is set in server.env (ordinal=300) and in microprofile-config.properties (ordinal=100), then the value from server.env will be used. By default, there are 3 default ConfigSources:

System.getProperties() (ordinal=400)
System.getenv() (ordinal=300)
All META-INF/microprofile-config.properties files on the ClassPath. (default ordinal=100, separately configurable via a config_ordinal property inside each file)

The following diagram demonstrates MicroProfile Config running in WebSphere Liberty. The server.env contains configurations with the ordinal of 300, while the files jvm.options and bootstrap.properties provide configurations with the ordinal of 400.

The default values can be specified in the file microprofile-config.properties within the application and the value can be overwritten for each deployment later on.

Fault Tolerance

Fault tolerance is about leveraging different strategies to guide the execution and result of some logic. Retry policies, bulkheads, timeouts and circuit breakers are popular concepts in this area. They dictate whether and when executions should take place, and fallbacks offer an alternative result when an execution does not complete successfully. Since covering all these aspects would be way too much at once, we will focus on just one of those: Circuit Breaker.

A circuit breaker offers a way of failing fast by automatically failing execution to prevent a system overload and indefinite wait or timeout by the clients.

Now that you have a basic idea what MicroProfile Config and MicroProfile Fault Tolerance mean, let’s see how property configuration and a circuit breaker work from a technical point of view.

@Inject
Config config;

public String getAllProperties(){

     StringBuilder out = new StringBuilder();
     for(ConfigSource source : config.getConfigSources()) {
        out.append(source.getName() + " - " + source.getOrdinal() + "\n");
     }

     for(String name : config.getPropertyNames()) {
        out.append(config.getValue(name, String.class) + "\n");
     }
     return out.toString();
}

@Inject

Config config;

public String getAllProperties(){

StringBuilder out = new StringBuilder();

for(ConfigSource source : config.getConfigSources()) {

out.append(source.getName() + " - " + source.getOrdinal() + "\n");

}

for(String name : config.getPropertyNames()) {

out.append(config.getValue(name, String.class) + "\n");

}

return out.toString();

}

After adding the MicroProfile dependency in you pom.xml, you can set up a simple class and just @Inject the configuration, which will then be available to the outside. Of course this is a very basic example of the configuration usage. It comes especially in handy when deploying your application to different environments and you are in the need of different values for the same property key.

/** If one request fails in a rolling window of 2 requests, the circuit 
* will be opened. The circuit will remain in the open state for 5 seconds 
* and then switch to half-open state. During the half-open state, 
* if a request fails, the circuit will switch back to open state. 
*/
@CircuitBreaker(requestVolumeThreshold=2, failureRatio=0.50, delay=5000, successThreshold=2)
public String viewDepartmentCount() throws ConnectException {
   counterForInvokingViewDepartments++;
   return viewDepartmentCountService();
}

/** If one request fails in a rolling window of 2 requests, the circuit

* will be opened. The circuit will remain in the open state for 5 seconds

* and then switch to half-open state. During the half-open state,

* if a request fails, the circuit will switch back to open state.

@CircuitBreaker(requestVolumeThreshold=2, failureRatio=0.50, delay=5000, successThreshold=2)

public String viewDepartmentCount() throws ConnectException {

counterForInvokingViewDepartments++;

return viewDepartmentCountService();

}

requestVolumeThreshold: The size of the rolling window used to determine failure threshold. The default is 20.
failureRatio: The minimum failure ratio in the rolling window to trigger the circuit breaker. The default is 0.5.
delay: The delay in milliseconds to transition to a half-open state after the circuit is open. The default is 5000 ms.
successThreshold: The number of consecutive successful invocations of the service required before closing the circuit. The default is 1.

Of course there is a lot more to discover! MicroProfile Open Tracing for example allows you to track requests through multiple systems – and of course there are more to come!

Please visit GitHub to experience an example of MircoProfile with all the fault tolerance and configuration aspects.

Enjoy and stay tuned!

MicroProfile with fault tolerance and configuration

Eclipse MicroProfile config

Fault Tolerance

Comment article

Recent posts

How can the MDC context be used in the reactive Spring applications

Spring Boot ConfigurationProperties on Base Classes in Kotlin

Reinforcement learning – Part 2: Getting started with Deep Q-Networks

API Gateways – An Evaluation of Zuul 2

Scale your Spring Boot Application in Kubernetes

Story slicing – benefits of the #NoEstimates approach