Closed danielchiaradia closed 2 years ago
Hi @danielchiaradia,
Thanks a lot for reaching out to us with your findings. We are aware of the issue and working on fixing this race condition. I will let you know as soon as progress is made here.
Regards, Kavitha
Update: A fix has been implemented and will presumably be available in the upcoming 3.61.0
which is expected for CW2 2022. We'll update here once it is available
FYI 3.61.0
is released now, so I'll close this. Please re-open should any problems remain.
Issue Description
If you configure caching for a call to the com.sap.cloud.sdk.cloudplatform.resilience.ResilienceDecorator the underlying com.sap.cloud.sdk.frameworks.resilience4j.Resilience4jDecorationStrategy will initialize the caches lazily in com.sap.cloud.sdk.frameworks.resilience4j.DefaultCachingDecorator.decorateCallable(Callable, ResilienceConfiguration). The decorator checks first if there is any cache present for the given name and will create one when the cache manager returns null. If you have two threads concurrently calling the ResilienceDecorator for the same service class then it can happen that both threads retrieve null from the cache manager and both threads try to create the cache. JCache will then synchronize the cache creation and throws an exception when there is already a cache for the given name. The result is that one thread creates the caches successfully and the other gets an exception.
The reason is the race condition in DefaultCachingDecorator#decorateCallable where the lookup and cache creation are not synchronized. This problem occurs only on the first call and only if there is more than one thread involved.
The call to the resilience execution looks more or less as follows:
Impact / Priority
Impact: Inconvenience. Users might see an error in the application have to redo their task (mostly searching for something).
Error Message
Dependencies
Project Details
[ ] Neo
Checklist