GitHub user AuroraTwinkle edited a discussion: What if pass downtime broker
nodes to serviceUrl parameter when building PulsarClient
I am a beginner in Pulsar, and I found a problem. When I create a PulsarClient,
if I pass a serviceUrl that contains multiple downtime broker nodes and a
normal broker node, then creating a Consumer or Producer will most likely fail
and throw an exception similar to the following:
```java
Exception in thread "main" org.apache.pulsar.client.api.PulsarClientException:
java.util.concurrent.ExecutionException:
org.apache.pulsar.client.api.PulsarClientException: Failed to subscribe
persistent://benchmark/ns-tPALz4g/test-0000000-jbw3YDo with 4 partitions
Connection already closed
at
org.apache.pulsar.client.api.PulsarClientException.unwrap(PulsarClientException.java:1111)
at
org.apache.pulsar.client.impl.ConsumerBuilderImpl.subscribe(ConsumerBuilderImpl.java:103)
```
By studying the source code, I found that when PulsarClient establishes a
connection with the broker, it selects a node in the serviceUrl for connection
in a round-robin order.
```java
@Override
public InetSocketAddress resolveHost() {
List<InetSocketAddress> list = addressList;
checkState(
list != null, "No service url is provided yet");
checkState(
!list.isEmpty(), "No hosts found for service url : " + serviceUrl);
if (list.size() == 1) {
return list.get(0);
} else {
int originalIndex = CURRENT_INDEX_UPDATER.getAndUpdate(this, last
-> (last + 1) % list.size());
return list.get((originalIndex + 1) % list.size());
}
}
```
I think there are some areas for improvement here. In the implementation of the
`ServiceNameResolver` interface, we can **perform periodic node detection and
corresponding removal or recovery operations to avoid selecting unhealthy nodes
when resolvingHost**, thereby improving the robustness of the program. If you
think this is an improvement, I will push a PR to solve this problem. Looking
forward to your suggestions, thanks!
GitHub link: https://github.com/apache/pulsar/discussions/22933
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
