In this article we will look at very simple basic example of Resilience4j bulkhead feature & look at runtime behavior of bulkhead. Here is the maven dependency for resilience4j-bulkhead required for this example.

Bulkhead Concept

Do not burden service with calls more than it can consume at a time. If call load is greater than service’s consumption at that time, then keep calls waiting for reasonable time until existing concurrent calls can finish & they can get turn. Otherwise just timeout the calls & go for alternate recovery path. This will avoid overloading of service & also give a graceful way to provide alternate recovery under heavy load.

Example in this article

Bulkhead Configurations: Maximum 5 concurrent calls at any given time. Keep other calls waiting for until one of the in-process 5 concurrent finishes or until maximum of 2 seconds.

• Create mock external service which takes 2 seconds to finish its processing.
• Create a service client which calls external service using bulkhead with above configurations.
• Mimic 20 parallel users/executions by calling service client in 20 threads.
• We will observe how bulkhead behaves for all threads.

Mock Service & client

Here is a mock service which takes 2 seconds to finish processing. Also a service client which decorates calls to external service using bulkhead. Bulkhead is configured to allow only 5 concurrent calls at a time. In case already 5 concurrent calls are in process, then it is configured to wait for maximum of 5 seconds.

Bulkhead in action

Here we will call service client in 20 parallel threads which might mimic 20 parallel users or 20 parallel executions.

Output

Key behavior to look for in output

• Service calls start:
  • At first you will see “Starting service call” for all 20 threads.
• 5 concurrent calls & other waiting:
  • Then you will see that service-call-1 till service-call-5 (5 concurrent threads) processing finished together around 17:01:27 while other threads were still waiting.
• Next 5 concurrent calls:
  • Then you will see that service-call-6 till service-call-10 (5 concurrent threads) processing finished together around 17:01:29
• Wait time over for last 5 calls:
  • Then you will see that service-call-16 till service-call-20 ended up with io.github.resilience4j.bulkhead.BulkheadFullException because 5 second wait time for them was over.
• Processing finished for remaining 5 calls:
  • Then you will see that service-call-11 till service-call-15 (5 concurrent threads) processing finished together around 17:01:31. These logs show after above exception which means these might be under process while above calls failed.

See Also

Resilience4j | Bulkhead vs. Rate Limiter

Resilience4j Tutorial | Basics with runtime behavior | Simple examples for beginners