You are viewing a plain text version of this content. The canonical link for it is here.

Posted to jira@kafka.apache.org by "Lianet Magrans (Jira)" <ji...@apache.org> on 2026/04/08 17:39:00 UTC

[jira] [Commented] (KAFKA-18812) Improve new consumer API errors upon background thread failures

    [ https://issues.apache.org/jira/browse/KAFKA-18812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072043#comment-18072043 ] 

Lianet Magrans commented on KAFKA-18812:
----------------------------------------

We don't have anyone working on this anymore, so free to take if anyone has bandwidth (and happy to help with reviews).

> Improve new consumer API errors upon background thread failures
> ---------------------------------------------------------------
>
>                 Key: KAFKA-18812
>                 URL: https://issues.apache.org/jira/browse/KAFKA-18812
>             Project: Kafka
>          Issue Type: Improvement
>          Components: clients, consumer
>            Reporter: Lianet Magrans
>            Priority: Major
>              Labels: consumer-threading-refactor
>
> The new consumer background thread could fail to start, in which case it will log an error and die. At the moment, the expectation is that consumer api calls will  fail with TimeoutException (KafkaException) when sending events to the background for processing and wait for responses (that will never be received).
> We should review to consider improving, given that seems pointless to wait for an event to be processed if we know the background thread is not running. Maybe we can propagate a clearer error message better
>  
> Note that once in this area, we should also review the errors propagated to the API if the background fails on a single run (runOnce), which also logs but the thread does not die. The expectation in this case is that individual API calls will fail when trying to access resources that may not be available (ex. a request manager). But each process within ApplicationEventProcessor handles this kind of situation differently, so we should improve it if we consider, consistently for all APIs 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)