curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <>
Subject Re: [DISCUSS] CURATOR-533
Date Mon, 29 Jul 2019 00:28:09 GMT
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
removing the existing implementation?

On Mon, Jul 29, 2019 at 2:50 AM Jordan Zimmerman <>

> 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 each ConnectionStateListener
> set in a Curator client. It turns out that this is not ideal. Instead, a
> shared CircuitBreaker should be used per Curator client.
> Unfortunately, the best way to do this is to remove the
> ConnectionStateListenerDecorator semantics and use a different mechanism.
> This Issue proposes to do this and remove ConnectionStateListenerDecorator.
> This is a breaking change but given the short amount of time it's been in
> Curator it's unlikely that it's been widely adopted.
> If the community considers a breaking change too harsh the older classes
> can be maintained for a while and marked as @Deprecated. Otherwise we can
> make the next release 4.3.0 (note: our semantic versioning has always been
> wrong - different issue) to denote a breaking change.
> I have a candidate PR here: <
>> - the Jira issue is:
> <
> -Jordan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message