Zili Chen created CURATOR-562:
---------------------------------
Summary: Remove ConnectionHandlingPolicy
Key: CURATOR-562
URL: https://issues.apache.org/jira/browse/CURATOR-562
Project: Apache Curator
Issue Type: Improvement
Components: Framework
Reporter: Zili Chen
Fix For: 5.0.0
Back to the day we bump Curator from 2.x to 3.0 we introduce
{{ConnectionHandlingPolicy}} as a bridge that provides different strategy on
handling different session timeout logic.
Things changed and now only the {{StandardConnectionHandlingPolicy}} survive,
who has two methods
1. {{checkTimeouts}} totally static utility. Besides, some values in
{{CheckTimeoutsResult}} seems out of day that we might have a follow-up to
handle it. Anyway, I don't thing anyone outside Curator should change the
behavior here since it is tight couple with how {{o.a.c.ConnectionState}} works.
2. {{callWithRetry}} it is actually a consignee of {{RetryLoop#callWithRetry}}.
According to its implementation it seems hardly an outside user can properly
define his {{callWithRetry}} method.
Thus, I propose that we flatten this legacy class.
DISCLAIMER:
The place from where I come here is CURATOR-544 that I'd like to implement a
user-friendly option to enable Curator blocks its regenerate ZooKeeper client
logic on {{SESSIONEXPIRED}}.
However, neither {{ConnectionHandlingPolicy}} nor {{RetryLoop}} nor
{{RetryPolicy}} is a good place since implementations coupled quite a bit. And
the real regeneration logic hided inside {{ConnectionState}}.
Thus I'm willing to do a bit code cleanups to see where we can properly inject
such logics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
