Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -105,9 +105,11 @@ public void initialize(SourceTaskContext context) {
public abstract List<SourceRecord> poll() throws InterruptedException;

/**
* <p>
* Commit the offsets, up to the offsets that have been returned by {@link #poll()}. This
* method should block until the commit is complete.
* This method is invoked periodically when offsets are committed for this source task. Note that the offsets
* being committed won't necessarily correspond to the latest offsets returned by this source task via
* {@link #poll()}. When exactly-once support is disabled, offsets are committed periodically and asynchronously
* (i.e. on a separate thread from the one which calls {@link #poll()}). When exactly-once support is enabled,
* offsets are committed on transaction commits (also see {@link TransactionBoundary}).
Comment thread
C0urante marked this conversation as resolved.
Outdated
* <p>
* SourceTasks are not required to implement this functionality; Kafka Connect will record offsets
* automatically. This hook is provided for systems that also need to store offsets internally

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on the fence on whether or not to remove this bit as well since I can't think of a realistic use-case where this method would help with offset tracking in the source system in its current form (and hence the question on deprecation of this method in https://issues.apache.org/jira/browse/KAFKA-15091).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "store offsets internally" language isn't great, but I'd rather leave it for now and explore it further if/when we start discussing deprecating this method. Connector developers might theoretically use this for acknowledging JMS records, for example, which in a very loose sense is storing offsets (or at least, some JMS-specific equivalent of them) in that system.

Expand Down