...
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.
Type: | long |
Default: | 300000 120000 (i.e. 5 2 minutes) |
Valid Values: | 0 - LONG_MAX |
Importance: | high |
...
Maintain the current code behavior and add a retry loop with a timeout.
Pros: Same logic, less code change.
Cons: Do users want to be blocked on instantiating the client? I don't like this idea.
Throw DNS resolution upon failing but no retry
Pros: No additional config is needed
Cons: This is a behavioral change, and the application owner might need to rewrite the exception handling, i.e. catching the DNS failure logic.
- No retry. The network client will continue to retry until it is interrupted.
- 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
- Cons: I think we should have some failure mechanism to notify users.
- Making BootstrapResolutionException retriable
- Pros: For the transient case, we might not even need a timeout, people are expected to retry on catching this exception
- 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
- Bing Combine DNS resolution and connection into a single timeout
- Pros: Explicit configuring of the time it takes to connect to DNSUsing a single timer to account for the connection time.
- Cons: Should we make connection retry fatal after the timeout? Maybe not.Cons: A bit deviate from the current use case. We think the behavior change can be too drastic