Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
KAFKA-18659: librdkafka compressed produce fails unless api versions returns produce v0 #18727
KAFKA-18659: librdkafka compressed produce fails unless api versions returns produce v0 #18727
Changes from 3 commits
a252374
243771e
8a5d335
6420650
b38a7ef
593db8b
55056f2
cff110c
4d0227a
04db4eb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Since listenerType is optional, could we add a comment when the caller is expected to pass in the right listenerType?
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.
Fair point, I updated this to have two methods so it's clear which one to be used when. One of them always take the API listener and the other one doesn't. There is only one non test usage of the latter currently.
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.
This simplification is unrelated to the main change in this PR - just something I noticed could be cleaned up.
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.
Use the same approach we use for requests for consistency - it should result in the same behavior, but fail more clearly if there is some inconsistency.
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.
Removed unused overloads.
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.
Instead of bringing back v0 and v1, could we just customize the minVersion of the produce ApiKey in ApiResponse?
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 am indeed exploring something involving customizing ApiKey/ApiResponse (that's what I meant when I said that there may be a cleaner way to make the change). But I was planning to leave 0-12 here and reduce the range within the code.
The main advantage is that you get appropriate errors if you try to produce with v0-2. The option you suggest would result in a disconnection. I think a disconnection is too confusing if the given version is included as part of the api versions response.
Thoughts?
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.
It seems that
UNSUPPORTED_VERSION
was added in 0.10.0 https://github.com/apache/kafka/pull/986/files#diff-0ae188e241ee35148145e7e04ed2acb3c20356650194f3603811c51b886ebe20. Produce v0/v1 already existed in 0.9. So, even if we sendUNSUPPORTED_VERSION
in the error, the 0.9 client won't be able to understand it. So, it really only helps with Produce v2 request.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 agree that it's nearly impossible to make the experience for these super ancient clients good. I was more thinking about client developers implementing the kafka protocol.
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.
Yes, we could make an effort to send a more meaningful error code for produce v0-v2. But since they are not really supported on the broker, just doing a disconnect like any other unsupported version also seems reasonable.
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.
This is for PartitionProduceData(). Could we make the indentation clearer?
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 removed a bunch of old version of other requests. If we just follow their approach by removing the old version from the protocol definition, there is no need to test the server rejection logic just for produce request, right?
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.
This one is different because we have the overrides - it's very difficult to ensure we don't regress as the code changes without a test. For the other cases, the logic is very simple (the versions that are not supported are not supported anywhere).
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.
It seems the primary purpose of retaining v0-v2 is to facilitate easier test writing. Perhaps we could create a
LegacyProduceRequest
json that mirrors the v0-v2 format exclusively for testing purposes?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.
That won't work, the separate file would not be able to use the same api key id.
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.
Pardon me, what is the issue of defining
"apiKey": 0
in other file (test scope) ? I createkafka/clients/src/test/resources/common/message/LegacyProduceRequest.json
according to v0-v2, and it works well.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 hadn't considered doing this in a different scope. I can try that and see if it works.
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 realized that there was a simple way - described it in the main PR.