[
https://issues.apache.org/jira/browse/KAFKA-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299107#comment-15299107
]
Guozhang Wang commented on KAFKA-3708:
--------------------------------------
Related commit to this ticket:
https://github.com/apache/kafka/pull/894
> Rethink exception handling in KafkaStreams
> ------------------------------------------
>
> Key: KAFKA-3708
> URL: https://issues.apache.org/jira/browse/KAFKA-3708
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 0.10.0.0
> Reporter: Guozhang Wang
> Assignee: Guozhang Wang
> Labels: user-experience
> Fix For: 0.10.1.0
>
>
> As for 0.10.0.0, the worker threads (i.e. {{StreamThreads}}) can possibly
> encounter the following runtime exceptions:
> 1) {{consumer.poll()}} could throw KafkaException if some of the
> configuration are not accepted, such as topics not authorized to read / write
> (security), session-timeout value not valid, etc; these exceptions will be
> thrown in the first ever {{poll()}}.
> 2) {{task.addRecords()}} could throw KafkaException (most likely
> SerializationException) if the deserialization fails.
> 3) {{task.process() / punctuate()}} could throw various KafkaException; for
> example, serialization / deserialization errors, state storage operation
> failures (RocksDBException, for example), producer sending failures, etc.
> 4) {{maybeCommit / commitAll / commitOne}} could throw various Exceptions if
> the flushing of state store fails, and when {{consumer.commitSync}} throws
> exceptions other than {{CommitFailedException}}.
> For all the above 4 cases, KafkaStreams does not capture and handle them, but
> expose them to users, and let users to handle them via
> {{KafkaStreams.setUncaughtExceptionHandler}}. We need to re-think if the
> library should just handle these cases without exposing them to users and
> kill the threads / migrate tasks to others since they are all not recoverable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
