merlimat opened a new pull request, #25676:
URL: https://github.com/apache/pulsar/pull/25676
### Motivation
`ExtensibleLoadManagerTest.startBroker` is a `@BeforeMethod` that runs
before each test method (e.g. `testStopBroker`, `testIsolationPolicy`) to make
sure all brokers are running and ready. Some test methods intentionally stop
brokers, so the next method's `startBroker` waits for those brokers to come
back.
The readiness check polled by creating a brand new `PulsarAdmin` per broker
on every poll iteration:
```java
for (BrokerContainer brokerContainer : pulsarCluster.getBrokers()) {
try (PulsarAdmin brokerAdmin = PulsarAdmin.builder()
.serviceHttpUrl(brokerContainer.getHttpServiceUrl()).build()) {
...
}
}
```
That's 3 brokers × N polls of admin builder/close, each one establishing a
new HTTP client. The connection setup work piles up against brokers that are
still warming up after a stop/restart and the await can exhaust its 180s budget.
Example failure:
https://scans.gradle.com/s/4dgsnjrtxayqa/tests/task/:tests:integration:integrationTest/details/org.apache.pulsar.tests.integration.loadbalance.ExtensibleLoadManagerTest/startBroker?top-execution=1
### Modifications
Build the per-broker `PulsarAdmin` clients once before the await loop and
reuse them across all poll iterations. Close them in a `finally` block. The
readiness checks themselves (`getActiveBrokers`, `createPartitionedTopic`,
`lookupPartitionedTopic`) are unchanged.
### Verifying this change
This change is already covered by the existing `ExtensibleLoadManagerTest`
integration test (which runs `startBroker` between every test method).
### Does this pull request potentially affect one of the following parts:
- [ ] Dependencies (add or upgrade a dependency)
- [ ] The public API
- [ ] The schema
- [ ] The default values of configurations
- [ ] The threading model
- [ ] The binary protocol
- [ ] The REST endpoints
- [ ] The admin CLI options
- [ ] The metrics
- [ ] Anything that affects deployment
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
