[ https://issues.apache.org/jira/browse/CURATOR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706910#comment-17706910 ]
Ryan Ruel commented on CURATOR-665: ----------------------------------- Thanks [~tison]. To confirm, yes I am using 5.4.0. I was able to get the NoAuth exception back using your example test above. In my case, I am using the "set" method with the CreateOption of "createParentsIfNeeded" (instead of update). After some further experimentation, I found that if the node already exists and my client (which doesn't have permission) tries to set or update it, I get the exception back just fine! However, if the node does NOT already exists and my client (again, which doesn't have permission) attempts to set the value, than I see client hang (and the exception is shown in the Curator logs but is swallowed). > ModeledFramework does not throw expected exception and instead hangs > -------------------------------------------------------------------- > > Key: CURATOR-665 > URL: https://issues.apache.org/jira/browse/CURATOR-665 > Project: Apache Curator > Issue Type: Bug > Components: Framework > Affects Versions: 5.4.0 > Reporter: Ryan Ruel > Priority: Major > > When writing data to ZooKeeper via Curator, I found that when I was receiving > a KeeperException NoAuth back from ZooKeeper, my call would hang indefinitely. > The NoAuth was expected as I was testing writing to a path where the ACL was > set to prevent my client from writing (X509 authentication scheme). > The call which hangs: > {code:java} > myFramework.set(myModel).toCompletableFuture().get();{code} > The logs from the call: > {code:java} > 2023-03-29 14:20:29,511 [Curator-Framework-0] ERROR imps.CuratorFrameworkImpl > - Background exception was not retry-able or retry gave up > org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = > NoAuth for /test/foo {code} > I'd expect this exception to bubble up wrapped in a CompletionException. > Instead, CuratorFrameworkImpl just logs the exception and then the call to > get() hangs indefinitely. -- This message was sent by Atlassian Jira (v8.20.10#820010)