Circuit Breaker Changes.

[rlakde]

No description provided.

[github-actions]

Code Coverage

Overall Project	43.08% -0.18%	🍏
Files changed	67.63%	🍏

Module	Coverage
here-naksha-storage-http	40.05% -1.56%	🍏
here-naksha-lib-handlers	34.39% -2.25%	🍏
here-naksha-lib-core	32.78%	🍏

Files

Module	File	Coverage
here-naksha-storage-http	CircuitBreakerProps.java	100%	🍏
	Resilience4jCircuitBreakerProvider.java	95.42% -4.58%	🍏
	RequestSender.java	87.42% -3.37%	🍏
	RequestSenderCache.java	81.25% -10.42%	🍏
	HttpStorageProperties.java	77.42% -12.9%	🍏
	HttpStorage.java	0% -10.64%	🍏
here-naksha-lib-handlers	IntHandlerForStorages.java	50.58% -22.17%	🍏
here-naksha-lib-core	NakshaVersion.java	42.31%	🍏

[github-actions]

Code Coverage

Overall Project	42.94% -0.17%	🍏
Files changed	45.06%	🍏

Module	Coverage
here-naksha-storage-http	36.34% -1.43%	🍏
here-naksha-lib-handlers	34.39% -2.25%	🍏
here-naksha-lib-core	32.79%	🍏

Files

Module	File	Coverage
here-naksha-storage-http	RequestSender.java	87.42% -3.37%	🍏
	RequestSenderCache.java	81.25% -10.42%	🍏
	HttpStorageProperties.java	77.42% -12.9%	🍏
	HttpStorage.java	0% -10.64%	🍏
here-naksha-lib-handlers	IntHandlerForStorages.java	50.58% -22.17%	🍏
here-naksha-lib-core	NakshaVersion.java	42.31%	🍏

[hirenkp2000]

My suggestion is not to mix RequestSenderCache and CircuitBreaker logic. They both are meant for different purposes, and can have its own update frequency/criteria.

Alternate better way, in my view is:

1. Implement CircuitBreakerCache in parallel to existing RequestSenderCache.
2. HttpStorage to getOrCreate CircuitBreaker instance as part of its constructor (similar to how it gets RequestSender cache currently)
3. And then make HttpStorageReadSession.execute and HttpStorageWriteSession.execute work under the control of cached CircuitBreaker instance. In this case, watchout for exception handling. We need to ensure that we return ErrorResult in case of CB exception and NOT propagate Exception directly.

Let me know, if by this approach, we are breaking some principle.