...
Allow the application owner to specify a retry period. The clients will fail after exceeding the timeout. The default set to 0s, which makes retry an opt-in config.
Pros: Allows users to have more control over how long to retry
Cons: Require a new config; client instantiation can block.
No retry. Let the application owner handle the DNS resolution exception. This means we would still throw a DNSLookupException upon failing.
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.
- Not throwing an exception but letting NetworkClient retry on poll.
- 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: The discussion thread mentioned that it wouldn't fail upon starting.
- Pros: No new configuration, simpler logic
- Cons: The consumer will be stuck in instantiation upon failed configuration. How do we interrupt the loop?