[Bug] C++ client cannot switch IPs when serviceUrl is a domain name with multiple resolved IPs

[zhangjialong666]

Search before asking

• I searched in the issues and found nothing similar.

Version

latest

Minimal reproduce step

1. Configure a DNS entry (e.g., pulsar.example.com) that resolves to multiple IP addresses.
2. Set the Pulsar C++ client serviceUrl to use this domain (e.g., pulsar://pulsar.example.com:6650).
3. Start the client and establish a connection.
4. Make one of the backend IPs unreachable (e.g., shut down the broker node or block traffic).
5. Observe the client behavior.

What did you expect to see?

• The client should retry failed connections with other resolved IPs.
• The client should automatically switch to a reachable IP without requiring manual reconfiguration or restart.

What did you see instead?

• The client attempts to connect only to one IP (usually the first one resolved).
• If that IP is unavailable, the client does not switch to other available IPs, leading to connection failures.

Anything else?

• This limits high availability when one backend node fails or becomes unreachable.
• The Java client is able to handle domains with multiple IPs by retrying other addresses. Having the C++ client behave consistently would improve resiliency.
• DNS resolution frequency and TTL may also affect the current behavior.

Are you willing to submit a PR?

• I'm willing to submit a PR!

[lhotari]

Sidenote (not directly related to multiple IP addresses for the DNS name):
For the Java client there were recent improvements in this area with PIP-425, https://github.com/apache/pulsar/blob/master/pip/pip-425.md . implementation in #24387 and some parts in #24574 (besides fixing flaky tests).

[zhangjialong666]

Sidenote (not directly related to multiple IP addresses for the DNS name): For the Java client there were recent improvements in this area with PIP-425, https://github.com/apache/pulsar/blob/master/pip/pip-425.md . implementation in #24387 and some parts in #24574 (besides fixing flaky tests).

OK, thanks for your reply. I will try it.

[BewareMyPower]

I'm adopting the new async_connect API provided by latest Asio library to get around of this issue in #477

Currently, the SDK leverages the async_connect method from socket that connects to a single endpoint: https://www.boost.org/doc/libs/1_88_0/doc/html/boost_asio/reference/basic_stream_socket/async_connect.html

However, it connects to the resolved addresses one by one with a configured connection timeout. When a resolved address takes much time to connect, the following addresses could be skipped.

With the async_connect function, the Asio library itself will find a best suitable address to connect. https://www.boost.org/doc/libs/1_88_0/doc/html/boost_asio/reference/async_connect.html