[Optimization] Improve Zookeeper startup wait logic in StartZookeeperWindowsProcessor
- Dominant language
- Java
- Stars
- 41.6k
- Forks
- 26.4k
- Avg merge
- 15h 13m
- Merged PRs (30d)
- 4
Description
### Pre-check
- [x] I am sure that all the content I provide is in English.
### Search before asking
- [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar feature requirement.
### Apache Dubbo Component
Java SDK (apache/dubbo)
### Descriptions
### Current Problem
In the current implementation of StartZookeeperWindowsProcessor.java, there is a hardcoded "ugly sleep":
TimeUnit.SECONDS.sleep(3);
As noted in the TODO comment, this is inefficient and "ugly." It leads to:
1. Flaky tests on slower CI environments (where 3s isn't enough).
2. Unnecessary delay on fast environments (where Zookeeper starts in <500ms).
### Proposed Change
I suggest replacing this fixed sleep with a proactive health check. Since the project already utilizes Apache Curator, we can leverage the blockUntilConnected() method to wait for the Zookeeper port to be ready, similar to how ResetZookeeperProcessor handles connections.
Also the catch Block should not swallow the errors.
This would align the Windows implementation with the Unix version's more reactive approach and improve overall test suite performance.
### Affected File
dubbo-test/dubbo-test-check/src/main/java/org/apache/dubbo/test/check/registrycenter/processor/StartZookeeperWindowsProcessor.java
### Related issues
_No response_
### Are you willing to submit a pull request to fix on your own?
- [ ] Yes I am willing to submit a pull request on my own!
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
Contributor guide
Research direction
Start with dubbo-test/dubbo-test-check/src/main/java/org/apache/dubbo/test/check/registrycenter/processor/StartZookeeperWindowsProcessor.java and compare its startup handling with ResetZookeeperProcessor. Replace the fixed three-second sleep with Curator's blockUntilConnected() approach, ensure the catch block does not swallow errors, and run the relevant test suite to confirm the startup wait is reliable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- distributed-systems
- Issue type
- Refactor
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 70/100