[ https://issues.apache.org/jira/browse/CURATOR-562?focusedWorklogId=789085&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-789085 ]
ASF GitHub Bot logged work on CURATOR-562: ------------------------------------------ Author: ASF GitHub Bot Created on: 08/Jul/22 17:13 Start Date: 08/Jul/22 17:13 Worklog Time Spent: 10m Work Description: tisonkun commented on PR #429: URL: https://github.com/apache/curator/pull/429#issuecomment-1179204884 Previous PR #348. cc @eolivelli @Randgalt @cammckenzie Issue Time Tracking ------------------- Worklog Id: (was: 789085) Time Spent: 3.5h (was: 3h 20m) > 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 > Assignee: Jordan Zimmerman > Priority: Major > Fix For: 5.0.0 > > Time Spent: 3.5h > 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.20.10#820010)