[
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)
