[GitHub] [kafka] badaiaqrandista commented on a diff in pull request #12416: KAFKA-13559: Fix issue where responses intermittently takes 300+ ms to respond, even when the server is idle.

[GitBox]

badaiaqrandista commented on code in PR #12416:
URL: https://github.com/apache/kafka/pull/12416#discussion_r927148782


##########
clients/src/main/java/org/apache/kafka/common/network/Selector.java:
##########
@@ -591,6 +591,11 @@ void pollSelectionKeys(Set<SelectionKey> selectionKeys,
                 long nowNanos = channelStartTimeNanos != 0 ? 
channelStartTimeNanos : currentTimeNanos;
                 try {
                     attemptWrite(key, channel, nowNanos);
+
+                    // Following is to fix KAFKA-13559. This will prevent 
poll() from blocking for 300 ms when the
+                    // socket has no data but the buffer has data. Only 
happens when using SSL.
+                    if (channel.hasBytesBuffered())
+                        madeReadProgressLastPoll = true;

Review Comment:
   @splett2 
   
   The `Selector` method getting called after channel is unmuted is actually 
`clearCompletedSends()` 
([here](https://github.com/apache/kafka/blob/a6c036256504b2549b009c10c777927a40a4bc34/clients/src/main/java/org/apache/kafka/common/network/Selector.java#L825-L827)).
   
   Few alternatives I can think of:
   
   1. Move `madeReadProgressLastPoll=true` to this method 
(`Selector.clearCompletedSends()`).
   2. Create a new `Selector` method named `readyForNextRead()` (or something) 
and call it from `SocketServer.processCompletedSends()`.
   
   What do you think?



-- 
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