[ 
https://issues.apache.org/jira/browse/CURATOR-648?focusedWorklogId=792742&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-792742
 ]

ASF GitHub Bot logged work on CURATOR-648:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 19/Jul/22 15:05
            Start Date: 19/Jul/22 15:05
    Worklog Time Spent: 10m 
      Work Description: jmalves opened a new pull request, #432:
URL: https://github.com/apache/curator/pull/432

   Addresses https://issues.apache.org/jira/browse/CURATOR-648 
   
   In my opinion the most likely resolution for this case is simply to fix the 
documentation, the changes in this PR do just that.




Issue Time Tracking
-------------------

            Worklog Id:     (was: 792742)
    Remaining Estimate: 0h
            Time Spent: 10m

> 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
>            Reporter: João Alves
>            Assignee: Jordan Zimmerman
>            Priority: Minor
>          Time Spent: 10m
>  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)

Reply via email to