[
https://issues.apache.org/jira/browse/KAFKA-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277885#comment-14277885
]
Jay Kreps edited comment on KAFKA-1863 at 1/14/15 11:33 PM:
------------------------------------------------------------
Hey guys, I put some thought into this but I agree it isn't very clearly
documented. Let's see if it makes sense:
ApiException denotes server-side exceptions and map to Kafka error codes. They
indicate a server or network error.
RetriableException are things that, if retried, might work. You want to avoid
retrying things like RecordTooLargeException because it is not going to change.
The next question is why do some exceptions get thrown by send() and some not?
First, obviously not all exceptions can be thrown by send() since the error may
occur asynchronously. So the choice is either to have all errors go to the
callback or not. The rationale for throwing some exceptions directly is that
these are things you should not ignore even if you don't wait on the future ---
e.g. a serialization error. The rationale for handling api exceptions in the
application thread was to simplify error handling. Some exceptions that can be
thrown by the server can also be thrown by the client --- e.g.
TimeoutException. It seems simpler to be able to say that timeout exceptions
will ALWAYS go to the callback even if the timeout occurs waiting on a metadata
update.
[~navina] I don't think I understand what you are saying. Is your objection
that the error can be handled in two different threads? Is that a problem?
Also, the producer has built in retries which will be a bit more efficient as
they retry using the serialized data, do those not work?
was (Author: jkreps):
Hey guys, I put some thought into this but I agree it isn't very clearly
documented. Let's see if it makes sense:
ApiException denotes server-side exceptions and map to Kafka error codes. They
indicate a server or network error.
RetriableException are things that, if retried, might work. You want to avoid
retrying things like RecordTooLargeException because it is not going to change.
The next question is why do some exceptions get thrown by send() and some not?
First, obviously not all exceptions can be thrown by send() since the error may
occur asynchronously. So the choice is either to have all errors go to the
callback or not. The rationale for throwing some exceptions directly is that
these are things you should not ignore even if you don't wait on the
future---e.g. a serialization error. The rationale for handling api exceptions
in the application thread was to simplify error handling. Some exceptions that
can be thrown by the server can also be thrown by the client---e.g.
TimeoutException. It seems simpler to be able to say that timeout exceptions
will ALWAYS go to the callback even if the timeout occurs waiting on a metadata
update.
[~navina] I don't think I understand what you are saying. Is your objection
that the error can be handled in two different threads? Is that a problem?
Also, the producer has built in retries which will be a bit more efficient as
they retry using the serialized data, do those not work?
> Exception categories / hierarchy in clients
> -------------------------------------------
>
> Key: KAFKA-1863
> URL: https://issues.apache.org/jira/browse/KAFKA-1863
> Project: Kafka
> Issue Type: Bug
> Reporter: Guozhang Wang
> Assignee: Guozhang Wang
> Fix For: 0.9.0
>
>
> In the new clients package we introduces a new set of exceptions, but its
> hierarchy is not very clear as of today:
> {code}
> RuntimeException -> KafkaException -> BufferExhastedException
> -> ConfigException
> ->
> SerializationException
> ->
> QuotaViolationException
> -> SchemaException
> -> ApiException
> ApiException -> InvalidTopicException
> -> OffsetMetadataTooLarge (probabaly need to be renamed)
> -> RecordBatchTooLargeException
> -> RecordTooLargeException
> -> UnknownServerException
> -> RetriableException
> RetriableException -> CorruptRecordException
> -> InvalidMetadataException
> -> NotEnoughtReplicasAfterAppendException
> -> NotEnoughReplicasException
> -> OffsetOutOfRangeException
> -> TimeoutException
> -> UnknownTopicOrPartitionException
> {code}
> KafkaProducer.send() may throw KafkaExceptions that are not ApiExceptions;
> other exceptions will be set in the returned future metadata.
> We need better to
> 1. Re-examine the hierarchy. For example, for producers only exceptions that
> are thrown directly from the caller thread before it is appended to the batch
> buffer should be ApiExceptions; some exceptions could be renamed / merged.
> 2. Clearly document the exception category / hierarchy as part of the release.
> [~criccomini] may have some more feedbacks for this issue from Samza's usage
> experience. [~jkreps]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
