Page History

...

1. 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.

   1. Pros: Allows users to have more control over how long to retry

   2. Cons: Require a new config; client instantiation can block.

2. No retry. Let the application owner handle the DNS resolution exception. This means we would still throw a DNSLookupException upon failing.

   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. Not throwing an exception but letting NetworkClient retry on poll.
   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: The discussion thread mentioned that it wouldn't fail upon starting.
   Retry indefinitely: Similar to option 1, but w/o a retry configuration
   1. Pros: No new configuration, simpler logic
   2. Cons: The consumer will be stuck in instantiation upon failed configuration. How do we interrupt the loop?