[
https://issues.apache.org/jira/browse/CURATOR-562?focusedWorklogId=789837&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-789837
]
ASF GitHub Bot logged work on CURATOR-562:
------------------------------------------
Author: ASF GitHub Bot
Created on: 12/Jul/22 04:12
Start Date: 12/Jul/22 04:12
Worklog Time Spent: 10m
Work Description: tisonkun commented on PR #429:
URL: https://github.com/apache/curator/pull/429#issuecomment-1181292829
@cammckenzie Yes the semantic should be identical. It's exactly a followup
to this comment
(https://github.com/apache/curator/pull/348#discussion_r389262170) where
`checkTimeout` has been removed but leaving code in this patch unchanged.
Actually we don't need `CuratorConnectionLossException` anymore, but
`logError` needs a placeholder exception. It'd be better if you can find an
existing exception as a good replacement.
Issue Time Tracking
-------------------
Worklog Id: (was: 789837)
Time Spent: 3h 50m (was: 3h 40m)
> 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: 3h 50m
> 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)
