Resilience4j | Bulkhead basics & runtime behavior | Simple example for beginners

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.


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

Leave a Reply

Your email address will not be published. Required fields are marked *