Hi,

can you share the exact version and the error logs that you are
experiencing?

Cheers,
Lucas

On Wed, May 6, 2026 at 12:35 PM Aayush Gupta via dev <[email protected]>
wrote:

> Hey team ,
>
> Looking for some Kafka Streams expertise on an issue we're investigating.
>
> Problem: A KafkaStreams-based consumer stops polling after ~15 minutes of
> topic inactivity. The adapter stays alive, but no messages are picked up
> until it's manually restarted. Reproduces on both IBM MQ-backed Kafka and
> Confluent Cloud.
>
> Suspected cause: Back-to-back expiry of connections.max.idle.ms
> <https://urldefense.com/v3/__http://connections.max.idle.ms__;!!Ayb5sqE7!qDd1fD9MUnSkUKBp87L-d7AAytECy6bSvnZr5Amy6Hm1ahQco5UP2P_hyAqUS2pAET4gJEEFVdMt3Wbtd3ciWA$>
>  (client,
> 9 min default) + broker idle timeout (~10 min). Stream thread dies on the
> next poll attempt, KafkaStreams goes to ERROR state silently — no
> StateListener or UncaughtExceptionHandler was registered, so nothing
> recovers.
>
> Questions:
>
> Is this a known pattern with KafkaStreams on idle topics? Any recommended
> approach?
> Is the close() + re-instantiate pattern safe? Any rebalance/duplicate
> risks?
> For Kafka 2.8+, should we prefer StreamsUncaughtExceptionHandler with
> REPLACE_THREAD instead of a full restart?
> Any input appreciated!
>
> Thanks
> Aayush Gupta
>
> *—*
> *Aayush Gupta*
> Software Engineer II
> Precisely.com
> <https://urldefense.com/v3/__http://www.precisely.com__;!!Ayb5sqE7!qDd1fD9MUnSkUKBp87L-d7AAytECy6bSvnZr5Amy6Hm1ahQco5UP2P_hyAqUS2pAET4gJEEFVdMt3Wb2Wa8pxQ$>
>
> p
>
>
> <https://urldefense.com/v3/__https://www.precisely.com/__;!!Ayb5sqE7!qDd1fD9MUnSkUKBp87L-d7AAytECy6bSvnZr5Amy6Hm1ahQco5UP2P_hyAqUS2pAET4gJEEFVdMt3WZXdns2VA$>
>
> ------------------------------
>
> ATTENTION: -----
> The information contained in this message (including any files transmitted
> with this message) may contain proprietary, trade secret or other
> confidential and/or legally privileged information. Any pricing information
> contained in this message or in any files transmitted with this message is
> always confidential and cannot be shared with any third parties without
> prior written approval from Precisely. This message is intended to be read
> only by the individual or entity to whom it is addressed or by their
> designee. If the reader of this message is not the intended recipient, you
> are on notice that any use, disclosure, copying or distribution of this
> message, in any form, is strictly prohibited. If you have received this
> message in error, please immediately notify the sender and/or Precisely and
> destroy all copies of this message in your possession, custody or control.
>

Reply via email to