-
Notifications
You must be signed in to change notification settings - Fork 15.4k
KAFKA-8615: Change to track partition time breaks TimestampExtractor #7054
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
0ac3cd9
5c39664
b9f3c99
ac606c5
bcd654a
5120315
682ef4c
d134740
91d9d2f
bfa788f
5cd7f22
7c66617
22f6f09
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -47,6 +47,7 @@ public class RecordQueue { | |
| private final ArrayDeque<ConsumerRecord<byte[], byte[]>> fifoQueue; | ||
|
|
||
|
ableegoldman marked this conversation as resolved.
|
||
| private StampedRecord headRecord = null; | ||
| private long partitionTime = RecordQueue.UNKNOWN; | ||
|
|
||
| private Sensor skipRecordsSensor; | ||
|
|
||
|
|
@@ -153,6 +154,7 @@ public long timestamp() { | |
| public void clear() { | ||
| fifoQueue.clear(); | ||
| headRecord = null; | ||
| partitionTime = RecordQueue.UNKNOWN; | ||
| } | ||
|
|
||
| private void updateHead() { | ||
|
|
@@ -167,7 +169,7 @@ private void updateHead() { | |
|
|
||
| final long timestamp; | ||
| try { | ||
| timestamp = timestampExtractor.extract(deserialized, timestamp()); | ||
| timestamp = timestampExtractor.extract(deserialized, partitionTime); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we also update method
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar, can we piggy-back some cleanup to
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ack to all...except the last point. We do check both for null..?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems, we check both for But I think they cannot be
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, misunderstood your question. Yes, either one could potentially be null if we don't yet have new records to process?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I agree the second null check should never happen. |
||
| } catch (final StreamsException internalFatalExtractorException) { | ||
| throw internalFatalExtractorException; | ||
| } catch (final Exception fatalUserException) { | ||
|
|
@@ -189,6 +191,11 @@ private void updateHead() { | |
| } | ||
|
|
||
| headRecord = new StampedRecord(deserialized, timestamp); | ||
|
|
||
| // update the partition timestamp if the current head record's timestamp has exceed its value | ||
|
ableegoldman marked this conversation as resolved.
Outdated
|
||
| if (timestamp > partitionTime) { | ||
| partitionTime = timestamp; | ||
| } | ||
|
ableegoldman marked this conversation as resolved.
Outdated
|
||
| } | ||
| } | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.