If the retry state has a null key it could be an error, but there
are real work scenarios where that just means "no information"
and the safest thing to do in that case is to simply not cache the
retry context (so the retry callback is executed "naturally" and
the exception bubbles up).
See comment in gh-49 about Spring AMQP use case
Using these you can get a pretty decent (if basic) hystrix-compatible
metrics stream. The "open" state of the circuit is exposed as
a RetryContext attribute for that purpose.
Circuit breakers, for instance, would like to store some state
for the duration of the lifetime of the circuit. So the normal
rule that the cache is not used until there is an error doesn't
make as much sense.
There were a couple of issues to fix here. The first was that only
the method arguments and not the method signature (or label) were
being used in the key generator. Plus the arguments were being
used as an array, which has a different hashcode on each invocation
(a Collection would be better). Plus the interceptor builder
didn't set the key generator in a circuit breaker, so all the method
calls with different args are unique and they are supposed to be the
same.
See gh-49
Really just a check that the existing metrics make sense. Next
step is to provide statistics for each circuit including
information on circuit status and timeouts.
User can manually configure a CircuitBreakerRetryPolicy
but needs to be careful to use stateful retry and
a RetryState where rollbackFor() is always false so that the
recovery is applied.
Better (probably) is to use @CircuitBreaker.
There doesn't seem to be much justification for throwing
RetryExhaustedException unconditionally when the context
is marked as exhausted. It would be better to behave,
as far as the caller is concerned, as if the cause had
been the original exception.
