You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #18412 I have tried to disable reconnections in tight loop in the http client. Some failing tests did uncover a problem with net::base_transport. That is, it does a DNS lookup for a random ipv4/ipv6 address and uses it. That will often fail on the first try if for example the local network doesn't support ipv6 (as it is in the failed tests in the linked PRs).
The test works in dev branch because after a few attempts we get lucky and finally get a working IP address. If we get the same address a few times in a row, or different address but of the same unsupported family (e.g. ipv6 in the test above) then we waste time on retrying to connect.
I believe it would be better to have the redpanda's net::base_transport cover that case. The DNS request already returns all addresses. We should try them one-by-one until our connection succeeds. Probably will need 2 DNS requests to get IPv6 and IPv4 addresses. Potential optimization is to race connecting to 2 addresses in parallel (like Golang transport does; dial.go can be used as inspiration).
Note: Extra care will need to be taken regarding timeouts. We will need to support a whole operation timeout/deadline and a shorter per-connection attempt timeout.
In #18412 I have tried to disable reconnections in tight loop in the http client. Some failing tests did uncover a problem with net::base_transport. That is, it does a DNS lookup for a random ipv4/ipv6 address and uses it. That will often fail on the first try if for example the local network doesn't support ipv6 (as it is in the failed tests in the linked PRs).
The test works in dev branch because after a few attempts we get lucky and finally get a working IP address. If we get the same address a few times in a row, or different address but of the same unsupported family (e.g. ipv6 in the test above) then we waste time on retrying to connect.
I believe it would be better to have the redpanda's net::base_transport cover that case. The DNS request already returns all addresses. We should try them one-by-one until our connection succeeds. Probably will need 2 DNS requests to get IPv6 and IPv4 addresses. Potential optimization is to race connecting to 2 addresses in parallel (like Golang transport does; dial.go can be used as inspiration).
Note: Extra care will need to be taken regarding timeouts. We will need to support a whole operation timeout/deadline and a shorter per-connection attempt timeout.
JIRA Link: CORE-2929
The text was updated successfully, but these errors were encountered: