lianetm commented on code in PR #16826:
URL: https://github.com/apache/kafka/pull/16826#discussion_r1707659860
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerCoordinator.java:
##########
@@ -1460,10 +1460,14 @@ public void handle(OffsetFetchResponse response,
RequestFuture<Map<TopicPartitio
if (responseError == Errors.COORDINATOR_LOAD_IN_PROGRESS) {
// just retry
future.raise(responseError);
- } else if (responseError == Errors.NOT_COORDINATOR) {
+ } else if (responseError == Errors.COORDINATOR_NOT_AVAILABLE ||
+ responseError == Errors.NOT_COORDINATOR) {
// re-discover the coordinator and retry
markCoordinatorUnknown(responseError);
future.raise(responseError);
+ } else if (responseError.exception() instanceof
RetriableException) {
+ // retry
+ future.raise(responseError);
Review Comment:
this is interesting. It makes total sense to me, but I remember that when we
revisited this for the new consumer, we were not sure if there was maybe a
reason behind this behaviour of failing for all unexpected errors on fetch,
even if retriable.
So back then we decided to keep it unchanged in the new consumer, but if
we're moving on to allow all retriables to be retried on fetch offsets, I guess
we only need align and behave the same in the new consumer (I will file a Jira
to review it)
--
https://issues.apache.org/jira/browse/KAFKA-17294
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
