You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jeff Holoman (JIRA)" <ji...@apache.org> on 2015/02/19 20:19:12 UTC
[jira] [Commented] (KAFKA-1929) Convert core kafka module to use
the errors in org.apache.kafka.common.errors
[ https://issues.apache.org/jira/browse/KAFKA-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327974#comment-14327974 ]
Jeff Holoman commented on KAFKA-1929:
-------------------------------------
Here's the list of duplicated errors
InvalidTopicException
LeaderNotAvailable - Used in scala producer
NotEnoughReplicasException
NotEnoughReplicasAfterAppendException
NotLeaderForPartitionException
OffsetMetadataTooLarge (Renaming to OffsetMetadataTooLargeException)
OffsetOutOfRangeException
UnkownTopicOrPartitionException - Also in scala producer
In most cases removing these from core and replacing the ErrorMapping with the error from o.a.k is an easy fix, the only real difference being that the errors in o.a.k present a different exception hierarchy.
All errors Extend RuntimeException -> KafkaException:
OffsetMetadataTooLarge | 12
NotEnoughReplicasException | 19
ApiException -> InvalidTopicException | 17
ApiException -> NotEnoughReplicasAfterAppendException | 20
ApiException -> RetriableException -> OffsetOutOfRange | 1
ApiException -> RetriableException -> UnkownTopicOrPartitionException | 3
ApiException -> RetriableException -> InvalidMetadataException -> LeaderNotAvailableException | 5
ApiException -> RetriableException -> InvalidMetadataException -> NotLeaderForPartitionException | 6
[~jkreps] you mentioned leaving the Scala clients as is, how do you want to handle UnknownTopicOrPartitionException
and LeaderNotAvailable which are in a number of different places in core?
Additionally, I noticed that OFFSET_LOAD_IN_PROGRESS, CONSUMER_COORDINATOR_NOT_AVAILABLE, and NOT_COORDINATOR_FOR_CONSUMER (which map to 14,15,16 in the protocol) are not mapped in Errors.java to named exceptions like their counterparts, instead implemented as ApiException. Is it worth implementing classes for these for consistency?
Thanks
Jeff
> Convert core kafka module to use the errors in org.apache.kafka.common.errors
> -----------------------------------------------------------------------------
>
> Key: KAFKA-1929
> URL: https://issues.apache.org/jira/browse/KAFKA-1929
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jay Kreps
> Assignee: Jeff Holoman
>
> With the introduction of the common package there are now a lot of errors duplicated in both the common package and in the server. We should refactor the server code (but not the scala clients) to switch over to the exceptions in common.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)