You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "John Roesler (JIRA)" <ji...@apache.org> on 2019/06/04 15:35:08 UTC

[jira] [Created] (KAFKA-8478) Poll for more records before forced processing

John Roesler created KAFKA-8478:
-----------------------------------

             Summary: Poll for more records before forced processing
                 Key: KAFKA-8478
                 URL: https://issues.apache.org/jira/browse/KAFKA-8478
             Project: Kafka
          Issue Type: Improvement
          Components: streams
            Reporter: John Roesler


While analyzing the algorithm of Streams's poll/process loop, I noticed the following:
The algorithm of runOnce is:

{code}
loop0:
  long poll for records (100ms)
  loop1:
    loop2: for BATCH_SIZE iterations:
      process one record in each task that has data enqueued
    adjust BATCH_SIZE
    if loop2 processed any records, repeat loop 1
    else, break loop1 and repeat loop0
{code}

There's potentially an unwanted interaction between "keep processing as long as any record is processed" and forcing processing after `max.task.idle.ms`.

If there are two tasks, A and B, and A runs out of records on one input before B, then B could keep the processing loop running, and hence prevent A from getting any new records, until max.task.idle.ms expires, at which point A will force processing on its other input partition. The intent of idling is to at least give A a chance of getting more records on the empty input, but under this situation, we'd never even check for more records before forcing processing.

I'm thinking we should only enforce processing if there was a completed poll since we noticed the task was missing inputs (otherwise, we may as well not bother idling at all).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)