[
https://issues.apache.org/jira/browse/CURATOR-648?focusedWorklogId=794953&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-794953
]
ASF GitHub Bot logged work on CURATOR-648:
------------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jul/22 15:50
Start Date: 25/Jul/22 15:50
Worklog Time Spent: 10m
Work Description: tisonkun commented on PR #432:
URL: https://github.com/apache/curator/pull/432#issuecomment-1194256981
@jmalves thank you! Merging...
Issue Time Tracking
-------------------
Worklog Id: (was: 794953)
Time Spent: 20m (was: 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: 20m
> 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)
