yashmayya commented on code in PR #13465:
URL: https://github.com/apache/kafka/pull/13465#discussion_r1165441821


##########
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/Worker.java:
##########
@@ -114,6 +127,7 @@ public class Worker {
 
     public static final long CONNECTOR_GRACEFUL_SHUTDOWN_TIMEOUT_MS = 
TimeUnit.SECONDS.toMillis(5);
     public static final long EXECUTOR_SHUTDOWN_TERMINATION_TIMEOUT_MS = 
TimeUnit.SECONDS.toMillis(1);
+    public static final long ALTER_OFFSETS_TIMEOUT_MS = 
TimeUnit.SECONDS.toMillis(5);

Review Comment:
   Hm but for non-exactly-once source connectors (which is the default mode), 
this would leave the door open to confusing behavior where users could get 
successful responses from the alter offsets API but the connector could 
completely ignore the overwritten offsets (if the user resumes the connector in 
the interim). I agree that the zombie task case is unhandled for non EoS source 
connectors, but at least that would only typically occur for misbehaving 
connector plugins whereas making the alter offsets API async would allow users 
to shoot themselves in the foot. I don't disagree that the 5 second timeout is 
quite non-ideal and even more concerning is the fact that if a connector's 
`alterOffsets` method hangs, it can disable a worker (something that was a big 
problem with other connector methods until your elegant fix in 
https://github.com/apache/kafka/pull/8069). I'm just trying to weigh the pros 
and cons here but it does seem like doing alter offset operations 
asynchronously in the
  worker has more benefits than drawbacks.



-- 
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: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to