You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Matthias J. Sax (Jira) via jira" <ji...@kafka.apache.org> on 2026/10/31 04:44:00 UTC

[jira] [Updated] (KAFKA-21407) StreamTask spams "not ready for processing" at INFO every 2 minutes for every idle task

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

Matthias J. Sax updated KAFKA-21407:
------------------------------------
    Affects Version/s:     (was: 4.3.0)
                           (was: 4.4.0)

> StreamTask spams "not ready for processing" at INFO every 2 minutes for every idle task
> ---------------------------------------------------------------------------------------
>
>                 Key: KAFKA-21407
>                 URL: https://issues.apache.org/jira/browse/KAFKA-21407
>             Project: Kafka
>          Issue Type: Bug
>          Components: streams
>    Affects Versions: 4.2.0
>            Reporter: Nicholas Telford
>            Priority: Minor
>
> h3. Problem
> KAFKA-19682 (#20693, first released in 4.2.0) made {{StreamTask#isProcessable}} log the reason when a task is not ready to process. {{StreamTask#maybeLogNotReady}} writes this reason at INFO, one time in each {{NOT_READY_LOG_INTERVAL_MS}} (120 s) while the task stays not ready:
> {code:java}
> private void maybeLogNotReady(final long wallClockTime, final String logMessage) {
>     final long timeSinceLastLog = lastNotReadyLogTime.map(aLong -> wallClockTime - aLong).orElse(-1L);
>     if (timeSinceLastLog >= NOT_READY_LOG_INTERVAL_MS) {
>         log.info(logMessage);
>         lastNotReadyLogTime = Optional.of(wallClockTime);
>     }
> }
> {code}
> The most frequent reason is the last branch of {{{}PartitionGroup#readyToProcess{}}}: "No partitions were buffered locally, so this task is not ready for processing." A task gets this result when none of its input partitions has buffered records. This is the normal state of a task whose input topics receive no new data, for example a task of a low-volume or a bursty topic.
> So an application logs one INFO line every 2 minutes for each idle task, for as long as the task stays idle. The line tells the operator nothing that needs an action. Before 4.2.0, {{PartitionGroup}} logged the same states at TRACE.
> h3. Impact
> We upgraded a Kafka Streams application from 3.8 to 4.4.0. It runs 12 instances with about 1,800 active tasks in total. Many of its source topics have a low volume.
>  * On 3.8, the application logged about 2,160 INFO lines per hour in steady state, almost all of them the {{StreamThread}} "Processed ... total records" summary.
>  * On 4.4.0, it logs about {*}58,000 INFO lines per hour{*}. 53,800 of them (93%) are the "not ready for processing" line from {{{}StreamTask{}}}.
> The count agrees with one line for each task every 2 minutes. The volume increases the cost of log storage, and the line hides the useful INFO lines of {{{}StreamTask{}}}.
> An operator cannot raise the level of the {{StreamTask}} logger to WARN to remove the line, because the same logger writes the task lifecycle at INFO: "Initialized", "Restored and ready to run", "Suspended", "Closed clean" and "Closed dirty". These lines are necessary to diagnose restores and rebalances. The only workaround is a filter on the message text in the logging backend.
> h3. Proposed fix
> Keep the diagnostic, but write it at INFO only when the task waits for a reason that is not normal. Possible approaches:
>  # Log the "no partitions were buffered locally" reason at DEBUG. Keep INFO for the reasons that mean the task waits for data that the broker has, or waits for a pending transaction commit.
>  # Log at INFO only when the task stayed not ready for longer than a threshold, for example {{max.task.idle.ms}} or a new configuration, and log at DEBUG before that.
>  # Use a separate logger name for the not-ready diagnostic, so that an operator can set its level without a change to the task lifecycle lines.
> If KAFKA-21372 changes {{ReadyToProcessResult}} to carry the reason as structured data, {{StreamTask}} can select the level from the reason with no text match.
> h3. Workaround
> A filter in the logging backend that denies INFO events of the {{org.apache.kafka.streams.processor.internals.StreamTask}} logger when the message ends with "not ready for processing.". This depends on the exact message text.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)