[jira] [Created] (KAFKA-9846) Race condition can lead to severe lag underestimate for active tasks

["Sophie Blee-Goldman (Jira)" <ji...@apache.org>]

Sophie Blee-Goldman created KAFKA-9846:
------------------------------------------

             Summary: Race condition can lead to severe lag underestimate for active tasks
                 Key: KAFKA-9846
                 URL: https://issues.apache.org/jira/browse/KAFKA-9846
             Project: Kafka
          Issue Type: Bug
          Components: streams
    Affects Versions: 2.5.0
            Reporter: Sophie Blee-Goldman


In KIP-535 we added the ability to query still-restoring and standby tasks. To give users control over how out of date the data they fetch can be, we added an API to KafkaStreams that fetches the end offsets for all changelog partitions and computes the lag for each local state store.

During this lag computation, we check whether an active task is in RESTORING and calculate the actual lag if so. If not, we assume it's in RUNNING and return a lag of zero. However, tasks may be in other states besides running and restoring; notably they first pass through the CREATED state before getting to RESTORING. A CREATED task may happen to be caught-up to the end offset, but in many cases it is likely to be lagging or even completely uninitialized.

This introduces a race condition where users may be led to believe that a task has zero lag and is "safe" to query even with the strictest correctness guarantees, while the task is actually lagging by some unknown amount.  During transfer of ownership of the task between different threads on the same machine, tasks can actually spend a while in CREATED while the new owner waits to acquire the task directory lock. So, this race condition may not be particularly rare in multi-threaded Streams applications



--
This message was sent by Atlassian Jira
(v8.3.4#803005)