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
   
    



##########
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]

Reply via email to