[ https://issues.apache.org/jira/browse/CURATOR-562?focusedWorklogId=403481&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-403481 ]
ASF GitHub Bot logged work on CURATOR-562: ------------------------------------------ Author: ASF GitHub Bot Created on: 14/Mar/20 17:52 Start Date: 14/Mar/20 17:52 Worklog Time Spent: 10m Work Description: TisonKun commented on issue #348: CURATOR-562 Remove ConnectionHandlingPolicy URL: https://github.com/apache/curator/pull/348#issuecomment-599109487 @Randgalt Thanks for your review and PR! I've merged it. ---------------------------------------------------------------- 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: 403481) Time Spent: 2.5h (was: 2h 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 > Priority: Major > Fix For: 5.0.0 > > Time Spent: 2.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.3.4#803005)