Greetings Lucas, I hope this message finds you well. We are currently using kafka-streams-3.4.0.jar, and at this time, we are not observing any error stacks or exceptions in the logs when the issue occurs. As part of our investigation, we wanted to check if there are any JVM flags or framework-level configurations that can be enabled to extract more detailed Kafka framework debug logs, particularly around Kafka Streams and consumer lifecycle behavior. During our review, I noticed that the client currently has the following Kafka consumer settings configured: [cid:cbe55115-d7f4-44f9-80ac-9ed7026d51f1] Based on our analysis:
* We recommended removing max.poll.interval.ms, as the configured value (50 seconds) is significantly lower than Kafka’s default of 5 minutes and may introduce unintended consumer instability. * We also suggested adding the following property instead: [cid:dddf00c0-3478-4f64-b516-4ed82717158a] * The intent is to increase the idle timeout to 30 minutes, as we suspect that the stream may be silently terminating after approximately 9 minutes of inactivity, which aligns with Kafka’s default idle connection behavior. At present, we are not seeing sufficient internal Kafka or Streams-level logging to determine whether: * the consumer is disconnecting, * the stream is stuck waiting, * heartbeats are failing, or * the client is repeatedly timing out and reconnecting. Given the absence of exceptions or diagnostic logs, it is unclear whether further tuning of Kafka consumer properties alone would meaningfully alleviate the issue without better visibility into the Kafka Streams internals. From your experience, do you have any recommendations beyond enabling more detailed Kafka/Streams logging—such as known patterns, specific stream-thread behaviors, or client-side recovery considerations—that we should be exploring in parallel? Any guidance would be greatly appreciated. Regards, Swathi BN- Swathi Kumar Senior Software Engineer Precisely.com ________________________________ From: Lucas Brutschy <[email protected]> Sent: Wednesday, May 6, 2026 10:04 AM To: [email protected] <[email protected]> Cc: Swathi Kumar <[email protected]>; Manoj Kumar <[email protected]>; Aayush Gupta <[email protected]> Subject: Re: Kafka Streams issue You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> This message originated Externally. Use proper judgement and caution with attachments, links, or responses. 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]<mailto:[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 [X]<https://urldefense.com/v3/__https://www.precisely.com/__;!!Ayb5sqE7!qDd1fD9MUnSkUKBp87L-d7AAytECy6bSvnZr5Amy6Hm1ahQco5UP2P_hyAqUS2pAET4gJEEFVdMt3WZXdns2VA$> [X] ________________________________ 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.
