[jira] [Assigned] (KAFKA-16393) SslTransportLayer doesn't implement write(ByteBuffer[], int, int) correctly

["Haruki Okada (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Haruki Okada reassigned KAFKA-16393:
------------------------------------

    Assignee: Haruki Okada

> SslTransportLayer doesn't implement write(ByteBuffer[], int, int) correctly
> ---------------------------------------------------------------------------
>
>                 Key: KAFKA-16393
>                 URL: https://issues.apache.org/jira/browse/KAFKA-16393
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Haruki Okada
>            Assignee: Haruki Okada
>            Priority: Minor
>
> As of Kafka 3.7.0, SslTransportLayer.write(ByteBuffer[], int, int) is implemented like below:
> {code:java}
> public long write(ByteBuffer[] srcs, int offset, int length) throws IOException {
>     ...
>     int i = offset;
>     while (i < length) {
>         if (srcs[i].hasRemaining() || hasPendingWrites()) {
>     ....
> {code}
> The loop index starts at `offset` and ends with `length`.
> However this isn't correct because end-index should be `offset + length`.
> Let's say we have the array of ByteBuffer with length = 5 and try calling this method with offset = 3, length = 1.
> In current code, `write(srcs, 3, 1)` doesn't attempt any write because the loop condition is immediately false.
> For now, seems this method is only called with args offset = 0, length = srcs.length in Kafka code base so not causing any problem though, we should fix this because this could introduce subtle bug if use this method with different args in the future.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)