[
https://issues.apache.org/jira/browse/KAFKA-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14360932#comment-14360932
]
Ewen Cheslack-Postava commented on KAFKA-2020:
----------------------------------------------
A bit more detail -- ReplicaNotAvailableException is reported in
MetadataResponses for partitions. I think it got put in the error code space
because there wasn't anywhere else to put it. But I'm not sure anything even
uses or needs this information. It's a pain point for anyone trying to use
protocol because the test for whether they received usable metadata isn't just
errorCode == NoError.
My very quick scan suggests this code/exception may only be used caught and
handled in a special way by ReplicaManager and that exception seems to be
generated internally, not from reading a MetadataResponse. This means it might
be feasible to just remove that error code. That's a protocol level change that
would definitely need a KIP. A bigger change would be to move that error to a
new field, but that only makes sense if there's actually a use case that
requires including it in the first place. I actually do think it provides
useful information for, e.g., admin purposes, it just isn't used by any clients
right now.
I also noticed while looking through the code for this that MetadataCache
includes the info it computes in the PartitionMetadata even if it encounters an
exception. However, if the exception is due to a leader not available, the
isrInfo is not computed. If we're going to include the info in the response
even in the case of some errors, it probably makes sense to always include all
of it. But again, this is a protocol change that might need a KIP, even if it
is minor.
A much smaller, simpler change is to make the change [~criccomini] was
suggesting -- don't make the utilities that convert error code -> exception and
throw the exception include that one error code. There are actually now two
versions of this. The Errors class in the clients module has similar
functionality and has the same issue, although it won't affect any of the
client code currently because they never call those methods on
MetadataResponses.
> I expect ReplicaNotAvailableException to have proper Javadocs
> -------------------------------------------------------------
>
> Key: KAFKA-2020
> URL: https://issues.apache.org/jira/browse/KAFKA-2020
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Reporter: Chris Riccomini
> Assignee: Neha Narkhede
>
> It looks like ReplicaNotAvailableException was copy and pasted from
> LeaderNotAvailable exception. The Javadocs were never changed. This means
> that users think that ReplicaNotAvailableException signifies leaders are not
> available. This is very different from, "I can ignore this exception," which
> is what the Kafka protocol docs say to do with ReplicaNotAvailableException.
> Related: what's the point of ReplicaNotAvailableException if it's supposed to
> be ignored?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
