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? cheers On Mon, Jul 29, 2019 at 2:50 AM Jordan Zimmerman <[email protected]> wrote: > 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: https://github.com/apache/curator/pull/320 < > https://github.com/apache/curator/pull/320> - the Jira issue is: > https://issues.apache.org/jira/browse/CURATOR-533 < > https://issues.apache.org/jira/browse/CURATOR-533> > > -Jordan
