blankensteiner commented on issue #56: URL: https://github.com/apache/pulsar-dotpulsar/issues/56#issuecomment-689827958
Hi @usaguerrilla Well, that doesn't really answer my questions. There are 3 kinds of exceptions. The ones where we know that retrying is the right thing to do. The ones where we know that retrying don't solve the problem and we, therefore, fault the consumer/producer/reader, thereby letting the user know what something is wrong. The ones where we don't know what the right action is. In those cases, we fault to consumer/producer/reader instead of risking retrying endlessly. We want to provide the best default actions and more importantly, we want to provide a way of defining your know logic. The 'Faulted' state is a final state, meaning that no retry/reconnect will ever happen, so the user is expected to handle that. This is by design, so it's not hanging but simply faulted. So, the question is what you are proposing. Do you want to discontinue the 'Faulted' state and always retry/reconnect no matter what kind of exception we get? Or are you suggesting changes to the default to retry more often? If the former, then writing a handler to monitor the exceptions and logging/alerting would be required by all users because otherwise, they will never know when some error makes the consumer/producer/reader retry/reconnect eternally. If the latter, then I think IOException is a very broad exception to always retry, and in the case of PersistenceException, I might worry of how to let the user know that something needs human attention, if not by faulting and throwing an exception? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
