-
Notifications
You must be signed in to change notification settings - Fork 15.4k
KAFKA-9629 Use generated protocol for Fetch API #9008
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 7 commits
56e4156
04538af
6094e4e
41d03d1
5c98083
8ca460c
3808a96
efdadc5
538ed00
155621b
89de508
7878289
701619d
82a0d46
38b2ebf
efa5450
2514f5a
e198797
cf3bf33
78cd012
507eb04
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 |
|---|---|---|
| @@ -0,0 +1,93 @@ | ||
| /* | ||
| * Licensed to the Apache Software Foundation (ASF) under one or more | ||
| * contributor license agreements. See the NOTICE file distributed with | ||
| * this work for additional information regarding copyright ownership. | ||
| * The ASF licenses this file to You under the Apache License, Version 2.0 | ||
| * (the "License"); you may not use this file except in compliance with | ||
| * the License. You may obtain a copy of the License at | ||
| * | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, software | ||
| * distributed under the License is distributed on an "AS IS" BASIS, | ||
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| */ | ||
|
|
||
| package org.apache.kafka.common.protocol; | ||
|
|
||
| import org.apache.kafka.common.record.BaseRecords; | ||
| import org.apache.kafka.common.record.MemoryRecords; | ||
| import org.apache.kafka.common.utils.ByteUtils; | ||
|
|
||
| import java.nio.ByteBuffer; | ||
|
|
||
| /** | ||
| * Implementation of Readable which reads from a byte buffer and can read records as {@link MemoryRecords} | ||
| * | ||
| * @see org.apache.kafka.common.requests.FetchResponse | ||
| */ | ||
| public class RecordsReader implements Readable { | ||
|
hachikuji marked this conversation as resolved.
Outdated
|
||
| private final ByteBuffer buf; | ||
|
|
||
| public RecordsReader(ByteBuffer buf) { | ||
| this.buf = buf; | ||
| } | ||
|
|
||
| @Override | ||
| public byte readByte() { | ||
| return buf.get(); | ||
| } | ||
|
|
||
| @Override | ||
| public short readShort() { | ||
| return buf.getShort(); | ||
| } | ||
|
|
||
| @Override | ||
| public int readInt() { | ||
| return buf.getInt(); | ||
| } | ||
|
|
||
| @Override | ||
| public long readLong() { | ||
| return buf.getLong(); | ||
| } | ||
|
|
||
| @Override | ||
| public double readDouble() { | ||
| return ByteUtils.readDouble(buf); | ||
| } | ||
|
|
||
| @Override | ||
| public void readArray(byte[] arr) { | ||
| buf.get(arr); | ||
| } | ||
|
|
||
| @Override | ||
| public int readUnsignedVarint() { | ||
| return ByteUtils.readUnsignedVarint(buf); | ||
| } | ||
|
|
||
| @Override | ||
| public ByteBuffer readByteBuffer(int length) { | ||
|
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. More of a side question, but is this length guaranteed to be less than the buffer size? Wondering if it is worth adding range checking.
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. This is copied straight from ByteBufferAccessor and will probably go away in a follow-on PR. But either way, looking at it it seems it should always be in range since this is used by zero-copy byte fields in the message classes, e.g. int len = _reader.readInt();
if (len > 0) {
this.someZeroCopyField = _reader.readByteBuffer(len);
}So generally it's probably safe. In the case of a corrupt message where the length is wrong, ByteBuffer#limit will throw an error and parsing will fail. It probably would be nice to put a range check in ByteBufferAccessor so we can throw a more useful error. |
||
| ByteBuffer res = buf.slice(); | ||
| res.limit(length); | ||
|
|
||
| buf.position(buf.position() + length); | ||
|
|
||
| return res; | ||
| } | ||
|
|
||
| @Override | ||
| public BaseRecords readRecords(int length) { | ||
| if (length < 0) { | ||
| // no records | ||
| return null; | ||
| } else { | ||
| ByteBuffer recordsBuffer = readByteBuffer(length); | ||
| return MemoryRecords.readableRecords(recordsBuffer); | ||
| } | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,141 @@ | ||
| /* | ||
| * Licensed to the Apache Software Foundation (ASF) under one or more | ||
| * contributor license agreements. See the NOTICE file distributed with | ||
| * this work for additional information regarding copyright ownership. | ||
| * The ASF licenses this file to You under the Apache License, Version 2.0 | ||
| * (the "License"); you may not use this file except in compliance with | ||
| * the License. You may obtain a copy of the License at | ||
| * | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, software | ||
| * distributed under the License is distributed on an "AS IS" BASIS, | ||
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| */ | ||
|
|
||
| package org.apache.kafka.common.protocol; | ||
|
|
||
| import org.apache.kafka.common.network.ByteBufferSend; | ||
| import org.apache.kafka.common.network.Send; | ||
| import org.apache.kafka.common.record.BaseRecords; | ||
| import org.apache.kafka.common.utils.ByteUtils; | ||
|
|
||
| import java.io.ByteArrayOutputStream; | ||
| import java.io.DataOutput; | ||
| import java.io.DataOutputStream; | ||
| import java.io.IOException; | ||
| import java.nio.ByteBuffer; | ||
| import java.util.function.Consumer; | ||
|
|
||
| /** | ||
| * Implementation of Writable which produces a sequence of {@link Send} objects. This allows for deferring the transfer | ||
| * of data from a record-set's file channel to the eventual socket channel. | ||
| * | ||
| * Excepting {@link #writeRecords(BaseRecords)}, calls to the write methods on this class will append to a byte array | ||
| * according to the format specified in {@link DataOutput}. When a call is made to writeRecords, any previously written | ||
| * bytes will be flushed as a new {@link ByteBufferSend} to the given Send consumer. After flushing the pending bytes, | ||
| * another Send is passed to the consumer which wraps the underlying record-set's transfer logic. | ||
| * | ||
| * For example, | ||
| * | ||
| * <pre> | ||
| * recordsWritable.writeInt(10); | ||
| * recordsWritable.writeRecords(records1); | ||
| * recordsWritable.writeInt(20); | ||
| * recordsWritable.writeRecords(records2); | ||
| * recordsWritable.writeInt(30); | ||
| * recordsWritable.flush(); | ||
| * </pre> | ||
| * | ||
| * Will pass 5 Send objects to the consumer given in the constructor. Care must be taken by callers to flush any | ||
| * pending bytes at the end of the writing sequence to ensure everything is flushed to the consumer. This class is | ||
| * intended to be used with {@link org.apache.kafka.common.record.MultiRecordsSend}. | ||
| * | ||
| * @see org.apache.kafka.common.requests.FetchResponse | ||
| */ | ||
| public class RecordsWriter implements Writable { | ||
|
mumrah marked this conversation as resolved.
Outdated
|
||
| private final String dest; | ||
| private final Consumer<Send> sendConsumer; | ||
| private final ByteArrayOutputStream byteArrayOutputStream; | ||
| private final DataOutput output; | ||
|
|
||
| public RecordsWriter(String dest, Consumer<Send> sendConsumer) { | ||
| this.dest = dest; | ||
| this.sendConsumer = sendConsumer; | ||
| this.byteArrayOutputStream = new ByteArrayOutputStream(); | ||
| this.output = new DataOutputStream(this.byteArrayOutputStream); | ||
| } | ||
|
|
||
| @Override | ||
| public void writeByte(byte val) { | ||
| writeQuietly(() -> output.writeByte(val)); | ||
|
mumrah marked this conversation as resolved.
Outdated
|
||
| } | ||
|
|
||
| @Override | ||
| public void writeShort(short val) { | ||
| writeQuietly(() -> output.writeShort(val)); | ||
| } | ||
|
|
||
| @Override | ||
| public void writeInt(int val) { | ||
| writeQuietly(() -> output.writeInt(val)); | ||
| } | ||
|
|
||
| @Override | ||
| public void writeLong(long val) { | ||
| writeQuietly(() -> output.writeLong(val)); | ||
|
|
||
| } | ||
|
|
||
| @Override | ||
| public void writeDouble(double val) { | ||
| writeQuietly(() -> ByteUtils.writeDouble(val, output)); | ||
|
|
||
| } | ||
|
|
||
| @Override | ||
| public void writeByteArray(byte[] arr) { | ||
| writeQuietly(() -> output.write(arr)); | ||
| } | ||
|
|
||
| @Override | ||
| public void writeUnsignedVarint(int i) { | ||
| writeQuietly(() -> ByteUtils.writeUnsignedVarint(i, output)); | ||
| } | ||
|
|
||
| @Override | ||
| public void writeByteBuffer(ByteBuffer src) { | ||
| writeQuietly(() -> output.write(src.array(), src.position(), src.remaining())); | ||
| } | ||
|
|
||
| @FunctionalInterface | ||
| private interface IOExceptionThrowingRunnable { | ||
| void run() throws IOException; | ||
| } | ||
|
|
||
| private void writeQuietly(IOExceptionThrowingRunnable runnable) { | ||
| try { | ||
| runnable.run(); | ||
| } catch (IOException e) { | ||
| throw new RuntimeException("Writable encountered an IO error", e); | ||
| } | ||
| } | ||
|
|
||
| @Override | ||
| public void writeRecords(BaseRecords records) { | ||
| flush(); | ||
| sendConsumer.accept(records.toSend(dest)); | ||
| } | ||
|
|
||
| /** | ||
| * Flush any pending bytes as a ByteBufferSend and reset the buffer | ||
| */ | ||
| public void flush() { | ||
| ByteBufferSend send = new ByteBufferSend(dest, | ||
| ByteBuffer.wrap(byteArrayOutputStream.toByteArray())); | ||
|
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. This creates a copy of the underlying bytes, can we avoid it?
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. Yea, it's possible, but rather complicated I think. We would need to manage our own byte array and grow it on-demand (like what happens in ByteArrayOutputStream). Then we could use
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. Would
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. Looks like the expansion factor for ByteArrayOutputStream varies on the JDK version. In JDK 8 and 11 it's 2x, but in JDK 14 it just grows the buffer to the minimum needed size. Our growth factor of 1.1 in ByteBufferOutputStream seems reasonable . Not to mention avoiding the final copy by using slice would be nice too.
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. @mumrah Thanks for checking this. However, the behavior in JDK 14 has not changed in that way. Performance would be atrocious if it did: private void ensureCapacity(int minCapacity) {
// overflow-conscious code
int oldCapacity = buf.length;
int minGrowth = minCapacity - oldCapacity;
if (minGrowth > 0) {
buf = Arrays.copyOf(buf, ArraysSupport.newLength(oldCapacity,
minGrowth, oldCapacity /* preferred growth */));
}The third parameter passed to
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. Looking a bit more, it seems like this will be mostly used by the data that precedes the actual records. Do we have a sense for what's the typical size for that? If we do, we can use that in the initial size and we can keep the
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. Thanks for the explanation, @ijuma. I missed the semantics of After the initial few top-level fields, each partition will have something like 38 bytes preceding its records (at a minimum, aborted transactions could increase that). Maybe we could increase initial capacity to 64 bytes?
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. Sounds good.
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. I increased the initial buffer size to 64 and also added 2x growth factor for the buffer. It occurred to me the initial size only really helps for the first partition's header fields, but beyond that (since we are reusing/growing the same ByteBufferOutputStream) we don't know what we'll need. The JMH benchmark did confirm that 2x was more performant than 1.1x for FetchResponse. Existing usages of ByteBufferOutputStream were not modified and still use 1.1x |
||
| sendConsumer.accept(send); | ||
| byteArrayOutputStream.reset(); | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,6 +17,7 @@ | |
| package org.apache.kafka.common.requests; | ||
|
|
||
| import org.apache.kafka.common.errors.UnsupportedVersionException; | ||
| import org.apache.kafka.common.message.FetchRequestData; | ||
| import org.apache.kafka.common.network.NetworkSend; | ||
| import org.apache.kafka.common.network.Send; | ||
| import org.apache.kafka.common.protocol.ApiKeys; | ||
|
|
@@ -146,7 +147,7 @@ public static AbstractRequest parseRequest(ApiKeys apiKey, short apiVersion, Str | |
| case PRODUCE: | ||
| return new ProduceRequest(struct, apiVersion); | ||
| case FETCH: | ||
| return new FetchRequest(struct, apiVersion); | ||
| return new FetchRequest(new FetchRequestData(struct, apiVersion), apiVersion); | ||
|
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. nit: any reason not to stick with the same constructor convention as the other requests?
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. I just wanted to remove the Struct constructor of FetchRequest completely. Eventually, |
||
| case LIST_OFFSETS: | ||
| return new ListOffsetRequest(struct, apiVersion); | ||
| case METADATA: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,5 +16,16 @@ | |
| */ | ||
| package org.apache.kafka.common.requests; | ||
|
|
||
| import org.apache.kafka.common.protocol.ApiMessage; | ||
|
|
||
| public interface AbstractRequestResponse { | ||
| /** | ||
| * Return the auto-generated `Message` instance if this request/response relies on one for | ||
| * serialization/deserialization. If this class has not yet been updated to rely on the auto-generated protocol | ||
| * classes, return `null`. | ||
| * @return | ||
| */ | ||
| default ApiMessage data() { | ||
|
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. Is there an advantage to pulling this up? Seems like we still need to update a bunch more classes. Until we have all the protocols converted, it might be safer to find another approach.
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. I have a PR that does need. I really need to get that over the line.
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. Perhaps instead we could add this to a mixin type. Then if we find cases where getting accessing to the
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. |
||
| return null; | ||
| } | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.