Table of Contents

Status

Current state: Under discussion.Accepted

Discussion thread: here  (Not happening yet)

...

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. Combine DNS resolution and connection into a single timeout
   1. Pros: Using 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 long