mjsax commented on code in PR #13533:
URL: https://github.com/apache/kafka/pull/13533#discussion_r1169326446
##########
streams/src/main/java/org/apache/kafka/streams/kstream/internals/ChangedSerializer.java:
##########
@@ -113,9 +113,9 @@ public byte[] serialize(final String topic, final Headers
headers, final Change<
throw new StreamsException("Both old and new values are not
null (" + data.oldValue
+ " : " + data.newValue + ") in ChangeSerializer,
which is not allowed unless upgrading.");
} else {
- final int capacity = UINT32_SIZE + newDataLength +
oldDataLength + NEW_OLD_FLAG_SIZE;
+ final int capacity = MAX_VARINT_LENGTH + newDataLength +
oldDataLength + NEW_OLD_FLAG_SIZE;
buf = ByteBuffer.allocate(capacity);
- ByteUtils.writeUnsignedInt(buf, newDataLength);
+ ByteUtils.writeVarint(newDataLength, buf);
Review Comment:
Yeah, it's a tradeoff (as pointed out on the PR description) -- I currently
tend to prefer the more complex code because writing into the repartition topic
is on the "hot data flow" path and thus seems worth the optimization. But if
others also fee it's not worth it, happy to change to just 4-byte int.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
