KAFKA-10818: Skip conversion to Struct when serializing generated requests/responses#7409
Conversation
|
Started a system tests run: https://jenkins.confluent.io/job/system-test-kafka-branch-builder/3052/ |
|
retest this please |
d4e4903 to
a009123
Compare
|
Scala 2.13 build passed, Scala 2.12 timed out, 2.11 failed due to H40 slave being offline. |
|
retest this please |
a44558e to
3106e35
Compare
There was a problem hiding this comment.
Need to verify that this condition is equivalent to the previous behavior of checking if the field exists.
|
retest this please |
211d9e0 to
47a197b
Compare
|
retest this please |
… on the auto generated protocol
…o generated protocol
…uses the auto generated protocol
…t-for-generated-requests * apache-github/trunk: MINOR: Fix flaky test shouldQueryOnlyActivePartitionStoresByDefault (apache#9681) KAFKA-10799 AlterIsr utilizes ReplicaManager ISR metrics (apache#9677) MINOR: Fix KTable-KTable foreign-key join example (apache#9683) KAFKA-10473: Add docs on partition size-on-disk, and other log-related metrics (apache#9276) KAFKA-10739; Replace EpochEndOffset with automated protocol (apache#9630) KAFKA-10460: ReplicaListValidator format checking is incomplete (apache#9326) KAFKA-10554; Perform follower truncation based on diverging epochs in Fetch response (apache#9382) MINOR: Align the UID inside/outside container (apache#9652) KAFKA-10794 Replica leader election is too slow in the case of too many partitions (apache#9675) KAFKA-10090 Misleading warnings: The configuration was supplied but i… (apache#8826) clients/src/main/java/org/apache/kafka/common/requests/OffsetsForLeaderEpochResponse.java clients/src/test/java/org/apache/kafka/clients/consumer/internals/FetcherTest.java core/src/test/scala/unit/kafka/server/epoch/util/ReplicaFetcherMockBlockingSend.scala
Also consolidate and clean-up.
| AbstractResponse response = AbstractResponse.parseResponse(apiKey, buffer, apiVersion); | ||
|
|
||
| // We correlate after parsing the response to avoid spurious correlation errors when receiving malformed | ||
| // responses |
|
Looks like the failures are unrelated, so this is ready for review @chia7712. The PR description needs a few tweaks, I will do that tomorrow. |
|
Actually, I went ahead and updated the PR description. |
| } | ||
|
|
||
| // Visible for testing | ||
| public final ByteBuffer serializeWithHeader(RequestHeader header) { |
There was a problem hiding this comment.
How about moving this method to test code? MessageTestUtil could be a good place.
There was a problem hiding this comment.
ditto for following "Visible for testing" code
There was a problem hiding this comment.
BTW, this method is duplicate to TestUtils#serializeRequestHeader
There was a problem hiding this comment.
This method serializes the request with the header while the test method serializes the header only. So, not a duplicate, right? Personally, I think it's useful for the class to be symmetric: it can parse from a buffer and serialize to a buffer. Do you have a concern that it may be misused?
There was a problem hiding this comment.
There is a reasonable argument that serializeBody is the counterpart to parse though and this particular method doesn't have to be here. I can buy that.
There was a problem hiding this comment.
Do you have a concern that it may be misused?
yes. Also the various serialization methods are a bit chaos to me :(
There was a problem hiding this comment.
Maybe we should move all testing-only serialization to a single utils (in test scope). I grep "static ByteBuffer" + "request/response" and MessageUtils, MessageTestUtil, RequestUtils and TestUtils have similar method interface.
There was a problem hiding this comment.
I have a refactoring that consolidates the logic around Send. But I think that would be best done in a separate PR since this PR is really massive. Since these methods are all in internal classes and are only used by tests, I suggest we keep them as they are for now and tackle these nits in the follow up PR.
There was a problem hiding this comment.
I have these changes locally, so I can submit them immediately after.
|
|
||
| public String toString(boolean verbose) { | ||
| return toStruct().toString(); | ||
| return data().toString(); |
There was a problem hiding this comment.
Is this toString variety still useful?
There was a problem hiding this comment.
I think so. Do you think it's not?
There was a problem hiding this comment.
Sorry, what do you mean by variety? The verbose boolean? Yes, that is useful for things like fetch and produce.
There was a problem hiding this comment.
It seems only ProduceRequest does produce verbose string. Maybe we can remove the toString(boolean verbose) as most requests does not generate verbose string. Also, ProduceRequest should override toString() to generate a verbose string always.
There was a problem hiding this comment.
The verbosity flag is used for request logging. Produce and fetch are the most important ones. The rest can be ignored. I don't see the benefit in removing this functionality.
| return data; | ||
| } | ||
|
|
||
| public void write(ByteBuffer buffer, ObjectSerializationCache serializationCache) { |
There was a problem hiding this comment.
This is used by testing only. Maybe we can move it to test scope.
chia7712
left a comment
There was a problem hiding this comment.
+1 to this great cleanup and improvement. Please merge it to trunk and then we can address the TODOs in separate PRs :)
Struct when serializing generated requests/responsesStruct when serializing generated requests/responses
|
Thanks for the review! Will post the follow up in a bit. |
|
Nice one @ijuma! |
|
Follow up PR submitted #9714 |
Generated request/response classes have code to serialize/deserialize directly to
ByteBufferso the intermediate conversion toStructcan be skipped for them.We have recently completed the transition to generated request/response classes,
so we can also remove the
Structbased fallbacks.Additional noteworthy changes:
AbstractRequest.parseRequesthas a more efficient computation of request size thatrelies on the received buffer instead of the parsed
Struct.SendBuilderforAbstractRequest/ResponsetoSend, made the superclassimplementation final and removed the overrides that are no longer necessary.
outside of tests.
OffsetFetchResponse's constructor when version >= 2.AbstractResponse.throttleTimeMs()abstract.toSendinSaslClientAuthenticatorinstead ofserialize.rely on the Data classes as much as possible when it comes to their state.
AbstractResponse.toString.getErrorResponseforProduceRequestandDescribeClientQuotasRequesttouse
ApiErrorwhich processes the error message sent back to the clients. This wasuncovered by an accidental fix to a
RequestResponseTesttest (it was callingAbstractResponse.toStringinstead ofAbstractResponse.toString(short)).Rely on existing protocol tests to ensure this refactoring does not change
observed behavior (aside from improved performance).
Committer Checklist (excluded from commit message)