You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "blankensteiner (via GitHub)" <gi...@apache.org> on 2023/01/26 13:14:05 UTC
[GitHub] [pulsar-dotpulsar] blankensteiner commented on issue #134: Correct placement for exception catching
blankensteiner commented on issue #134:
URL: https://github.com/apache/pulsar-dotpulsar/issues/134#issuecomment-1404991068
Hi @VisualBean
I'll answer the latter first: If a producer, consumer, or reader (p/c/r) has faulted you should dispose it and create a new one. However, when something has faulted and you might want to alert someone since the chances of it working just by creating a new p/c/r are not high (because it's usually a "permanent" networking, authentication, or broker/proxy issue).
You can, via the exception handler, help DotPulsar determine whether a specific exception should fault the p/c/r or if DotPulsar should just retry the operation. When faulting a p/c/r the user's tasks (from calling Send, Receive, and so on) will throw exceptions.
You shouldn't care about exceptions when monitoring the state and the exception handler is only for helping DotPulsar's internal retry logic. Expect that any call to a p/c/r can throw an exception and the operation can possibly be retried on a new p/c/r.
You are experiencing a consumer that stops receiving messages, but the call to Receive has not thrown an exception? If yes I would expect the consumer's state to be either "Inactive" or "Disconnected". Does that sound plausible?
--
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.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org