Table of Contents

Status

Current state: Under discussion.Accepted

Discussion thread: here  (Not happening yet)

...

The proposed configuration specifies the maximum amount of time clients can spend trying to resolve for the bootstrap server address. If the resolution cannot be completed within this timeframe, a BootstrapResolutionException will be thrown.

...

1. Maintain the current code behavior and add a retry loop with a timeout.

   1. Pros: Same logic, less code change.

   2. Cons: Do users want to be blocked on instantiating the client? I don't like this idea.

2. Throw DNS resolution upon failing but no retry

   1. Pros: No additional config is needed

   2. Cons: This is a behavioral change, and the application owner might need to rewrite the exception handling, i.e. catching the DNS failure logic.

3. No retry.  The network client will continue to retry until it is interrupted.
   
   1. Pros: No compatibility break. No additional exception handling logic, the network client will just log the error and continue to retry upon the next poll
   2. Cons: I think we should have some failure mechanism to notify users.
4. Making BootstrapResolutionException retriable
   1. Pros: For the transient case, we might not even need a timeout, people are expected to retry on catching this exception
   2. Cons: Then we reply on alerting mechanism to alert users the issue. If it is indeed a configuration issue, then it is harder to discover
5. Bing Combine DNS resolution and connection into a single timeout
   1. Pros: Explicit configuring of the time it takes to connect to DNSUsing a single timer to account for the connection time.
   2. Cons: Should we make connection retry fatal after the timeout? Maybe not.
6. 5min default timeout
   1. We've decided to reduce it to 2min to stay coherent to the delivery.timeout.ms
   2. 5min can be too longCons: A bit deviate from the current use case. We think the behavior change can be too drastic