[
https://issues.apache.org/jira/browse/CURATOR-562?focusedWorklogId=403408&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-403408
]
ASF GitHub Bot logged work on CURATOR-562:
------------------------------------------
Author: ASF GitHub Bot
Created on: 14/Mar/20 09:01
Start Date: 14/Mar/20 09:01
Worklog Time Spent: 10m
Work Description: TisonKun commented on pull request #348: CURATOR-562
Remove ConnectionHandlingPolicy
URL: https://github.com/apache/curator/pull/348#discussion_r392569778
##########
File path: curator-client/src/main/java/org/apache/curator/ConnectionState.java
##########
@@ -18,7 +18,6 @@
*/
Review comment:
I agree and the first time I notice this `ConnectionState` with
`curator-framwork`'s `ConnectionState`, it really confused me. But we can
separated the refactor or anything on this `ConnectionState` in another pass
IMO.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 403408)
Time Spent: 2h (was: 1h 50m)
> 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
> Priority: Major
> Fix For: 5.0.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> 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)
