Major Description
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.
Attachments
Issue Links
- links to
