-
Notifications
You must be signed in to change notification settings - Fork 15.4k
KAFKA-9669; Loosen validation of inner offsets for older message formats #8647
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 all commits
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 |
|---|---|---|
|
|
@@ -366,16 +366,6 @@ private[log] object LogValidator extends Logging { | |
| else None | ||
| } | ||
|
|
||
| def validateOffset(batchIndex: Int, record: Record, expectedOffset: Long): Option[ApiRecordError] = { | ||
| // inner records offset should always be continuous | ||
| if (record.offset != expectedOffset) { | ||
| brokerTopicStats.allTopicsStats.invalidOffsetOrSequenceRecordsPerSec.mark() | ||
| Some(ApiRecordError(Errors.INVALID_RECORD, new RecordError(batchIndex, | ||
| s"Inner record $record inside the compressed record batch does not have " + | ||
| s"incremental offsets, expected offset is $expectedOffset in topic partition $topicPartition."))) | ||
| } else None | ||
| } | ||
|
|
||
| // No in place assignment situation 1 | ||
| var inPlaceAssignment = sourceCodec == targetCodec | ||
|
|
||
|
|
@@ -423,8 +413,15 @@ private[log] object LogValidator extends Logging { | |
| if (batch.magic > RecordBatch.MAGIC_VALUE_V0 && toMagic > RecordBatch.MAGIC_VALUE_V0) { | ||
|
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. First, I don't fully understand the different between version 0, 1, and 2. I am concern if this check (
For 1, is it because we are only allow to update it in v1 and v2? E.g. For 2. is it because in place assignment is always false for
Contributor
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. For 1), it is because the v0 format has no field for the timestamp. For 2), you are right: we never do in place assignment for v0 because it does not support relative internal offsets. |
||
| if (record.timestamp > maxTimestamp) | ||
| maxTimestamp = record.timestamp | ||
| validateOffset(batchIndex, record, expectedOffset) | ||
| } else None | ||
|
|
||
| // Some older clients do not implement the V1 internal offsets correctly. | ||
| // Historically the broker handled this by rewriting the batches rather | ||
| // than rejecting the request. We must continue this handling here to avoid | ||
| // breaking these clients. | ||
| if (record.offset != expectedOffset) | ||
|
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 add a comment here? |
||
| inPlaceAssignment = false | ||
| } | ||
| None | ||
| } | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit nervous about this method being in the public interface. Could we make it package private and then add a test utility method in the same package that calls it, exposing it only for tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, we already have a public
appendUncheckedWithOffsetforLegacyRecord.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could move these methods to a
TestMemoryRecordsBuilderor something. I think risk of misuse is probably not high though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Since we already had one such method, I'm ok with keeping as is.