Skip to content

KAFKA-12233: Align the length passed to FileChannel by FileRecords.writeTo #9970

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.

Sign up for GitHub

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

Merged
chia7712 merged 4 commits into from
Jan 27, 2021
Merged

KAFKA-12233: Align the length passed to FileChannel by FileRecords.writeTo #9970

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
32eee57
KAFKA-12233: set length incorrectly
Jan 25, 2021
e5efce9
KAFKA-12233: set length incorrectly
Jan 25, 2021
a3a4ea5
add comment
Jan 26, 2021
5864444
resolve qa problems
Jan 26, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion clients/src/main/java/org/apache/kafka/common/record/FileRecords.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -278,7 +278,7 @@ public long writeTo(TransferableChannel destChannel, long offset, int length) th
file.getAbsolutePath(), oldSize, newSize));

long position = start + offset;
int count = Math.min(length, oldSize);
long count = Math.min(length, oldSize - offset);

@junrao junrao Jan 26, 2021

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is called from SocketServer through RecordsSend. The expectation is that the underlying file channel has enough bytes to return for the requested length. Normally this should be the case. If for some reason this is not true, by bounding the transfer amount by the remaining bytes in the file channel will cause RecordsSend.writeTo() to be called in a loop until the request times out. This may hide a real problem.

Perhaps what we could do is to throw an IllegalStateException if the file channel doesn't have enough bytes left. This will cause the socket channel to be closed and the Selector to log a warning.

@chia7712 chia7712 Jan 26, 2021

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps what we could do is to throw an IllegalStateException if the file channel doesn't have enough bytes left. This will cause the socket channel to be closed and the Selector to log a warning.

Please update docs for related writeTo methods if we want to apply this behavior. The current code use return value to calculate the length for next write. The return value gets redundant since the number of transferred data is always equal to expected length (it throws exception when there is no enough bytes left).

return destChannel.transferFrom(channel, position, count);
}

Expand Down
23 changes: 23 additions & 0 deletions clients/src/test/java/org/apache/kafka/common/record/FileRecordsTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,11 +20,13 @@
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.header.Header;
import org.apache.kafka.common.header.internals.RecordHeader;
import org.apache.kafka.common.network.TransferableChannel;
import org.apache.kafka.common.utils.MockTime;
import org.apache.kafka.common.utils.Time;
import org.apache.kafka.test.TestUtils;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import java.io.File;
import java.io.IOException;
Expand All @@ -51,7 +53,9 @@
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.junit.jupiter.api.Assertions.fail;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.ArgumentMatchers.anyLong;
import static org.mockito.ArgumentMatchers.eq;
import static org.mockito.Mockito.atLeastOnce;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.times;
Expand Down Expand Up @@ -512,6 +516,25 @@ public void testConversion() throws IOException {
doTestConversion(CompressionType.GZIP, RecordBatch.MAGIC_VALUE_V2);
}

@Test
public void testBytesLengthOfWriteTo() throws IOException {

int size = fileRecords.sizeInBytes();
long firstWritten = size / 3;

TransferableChannel channel = Mockito.mock(TransferableChannel.class);

// Firstly we wrote some of the data
fileRecords.writeTo(channel, 0, (int) firstWritten);
verify(channel).transferFrom(any(), anyLong(), eq(firstWritten));

// Ensure (length > size - firstWritten)
int secondWrittenLength = size - (int) firstWritten + 1;
fileRecords.writeTo(channel, firstWritten, secondWrittenLength);
// But we still only write (size - firstWritten), which is not fulfilled in the old version
verify(channel).transferFrom(any(), anyLong(), eq(size - firstWritten));
}

private void doTestConversion(CompressionType compressionType, byte toMagic) throws IOException {
List<Long> offsets = asList(0L, 2L, 3L, 9L, 11L, 15L, 16L, 17L, 22L, 24L);

Expand Down