tls-channel icon indicating copy to clipboard operation
tls-channel copied to clipboard

TlsChannel does not indicate channel as ready for I/ O operation in case less reads than available are made

Open kortemik opened this issue 8 months ago • 8 comments

I use a scenario where I receive data from a client connection as follows

int nReady = selector.select(this.readTimeout);
        if (nReady == 0) {
            throw new TimeoutException("read timed out");
        }
Set<SelectionKey> polledEvents = this.selector.selectedKeys();
Iterator<SelectionKey> eventIter = polledEvents.iterator();
while (eventIter.hasNext()) {
            SelectionKey currentKey = eventIter.next();
            System.err.println("currentKey <" + currentKey + ">");
            // tlsChannel needs to know about both
            if (currentKey.isReadable() || currentKey.isWritable()) {
                try {
                    readBytes = tlsChannel.read(byteBuffer);
}
} catch (Exception e) {
// something
}
eventIter.remove();
}

If server has sent a with multiple calls to write or with an array of buffers, does not differ:

                for (ByteBuffer byteBuffer : byteBufferList) {
                    long bytesWritten = establishedContext.socket().write(new ByteBuffer[] {
                            byteBuffer
                    });
                    LOGGER.info("wrote <{}>", bytesWritten);
                }

then tlsChannel is read only once and it does not trigger ready operation in the next invocation to selector.select. the data is unavailable and lost, however if the client code is changed so that:

while (true) {
readBytes = tlsChannel.read(byteBuffer);
if (readBytes <= 0) {
break;
}
}

all data is available and read, however expected behaviour is that selector would be ready immediately as there is still data not read. this change does not comform my needs because client buffers may be smaller than send buffers, however in the where we see the abnormal behviour they are larger.

kortemik avatar May 27 '24 08:05 kortemik