Thanks for the updated explanation, that certainly makes sense.
On Mon, Jul 29, 2019 at 10:47 AM Jordan Zimmerman <
jor...@jordanzimmerman.com> wrote:
> Sure - makes sense Cameron..
>
> When CURATOR-533 was written, each ConnectionStateListener created was
> mapped a new CircuitBreaker instance.
Sure - makes sense Cameron..
When CURATOR-533 was written, each ConnectionStateListener created was mapped a
new CircuitBreaker instance. In hindsight, this doesn't make sense. Only a
single, shared CircuitBreaker is needed. Here's the email that the Elastic
engineer sent to me originally that
hey Jordan,
Can you expand on why the previous implementation was not ideal?
Given that the decorator approach was only introduced recently, I don't
imagine it has had a lot of uptake, but it may be worth asking the question
on the curator-user list to work out if there's going to be any impact in
Hi Committers,
CURATOR-505 introduced circuit breaking behavior via
CircuitBreakingConnectionStateListener and ConnectionStateListenerDecorator.
Elastic has been using it with success but reports that the implementation can
be improved. The existing implementation uses a new CircuitBreaker for
