You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Zili Chen (Jira)" <ji...@apache.org> on 2022/07/25 15:52:00 UTC

[jira] [Updated] (CURATOR-648) CuratorFramework#blockUntilConnected does now wait forever if waitTime <= 0

     [ https://issues.apache.org/jira/browse/CURATOR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Zili Chen updated CURATOR-648:
------------------------------
    Component/s: Documentation

> CuratorFramework#blockUntilConnected does now wait forever if waitTime <= 0
> ---------------------------------------------------------------------------
>
>                 Key: CURATOR-648
>                 URL: https://issues.apache.org/jira/browse/CURATOR-648
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: João Alves
>            Assignee: Zili Chen
>            Priority: Minor
>             Fix For: 5.4.0
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> CuratorFramework#blockUntilConnected documentation remarks the following: 
> {noformat}
> maxWaitTime - The maximum wait time. Specify a value <= 0 to wait indefinitely{noformat}
> This does not seem to be correct, if _maxWaitTime <= 0_ then _blockUntilConnected_ returns immediately.
> I am able to reproduce this behaviour locally and from the code it is apparent to me that the cause is the logic in {_}ConnectionStateManager#blockUntilConnected{_}:
> {code:java}
> boolean hasMaxWait = (units != null);{code}
> Not sure what if the current behaviour is intended but I think misalignment probably should be fixed to prevent unexpected behaviour.
> What is the suggested fix here for this mismatch?
> If the implementation is changed to wait indefinitely, would it make sense to introduce a new method in _CuratorFramework_  to check the current curator connection state without having to wait?
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)