Yes that's the point. And I figured out the original ticket in FLINK trying to fix an unreasonable scenario where ZK lost permanently.
Best, tison. Jordan Zimmerman <[email protected]> 于2021年4月20日周二 下午4:29写道： > If the ZK connection is permanently lost what would you expect NodeCache > to do? > > -Jordan > > > On Apr 20, 2021, at 1:27 AM, tison <[email protected]> wrote: > > > > Yes I notice that. The production case is that the connection is lost > > "permanently"[1]. > > > > Best, > > tison. > > > > [1] > > > https://issues.apache.org/jira/browse/FLINK-18677?focusedCommentId=17168001&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17168001 > > > > > > Jordan Zimmerman <[email protected]> 于2021年4月20日周二 上午1:49写道： > > > >> Once the connection is repaired NodeCache is supposed to reconnect. You > >> can see the code here: > >> > >> > >> > https://github.com/apache/curator/blob/master/curator-recipes/src/main/java/org/apache/curator/framework/recipes/cache/NodeCache.java#L75 > >> < > >> > https://github.com/apache/curator/blob/master/curator-recipes/src/main/java/org/apache/curator/framework/recipes/cache/NodeCache.java#L75 > >>> > >> > >> If it's not, it's some kind of bug. > >> > >>> On Apr 19, 2021, at 3:25 PM, tison <[email protected]> wrote: > >>> > >>> Hi Curators, > >>> > >>> Recently I found a case that NodeCache would do nothing if ZK is really > >>> lost. It is by design? I can workaround this issue by adding connection > >>> listener handling ConnectionState.{SUSPENDED, LOST} though. > >>> > >>> Best, > >>> tison. > >> > >> > >
