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
