Hi Swathi, There is no ticket — feel free to file a KAFKA Jira if you believe you've found a bug. That said, 3.4.0 will not receive a fix; so upgrading to a current release is the right path.
connections.max.idle.ms should just close the idle connection — the Java client reconnects transparently on the next request. It does not crash the StreamThread, and I'm not aware of a 3.4.0 bug that would cause that. Hope that helps, Lucas On Tue, May 12, 2026 at 4:00 PM Swathi Kumar <[email protected]> wrote: > Morning Lucas. > > Is there an update on this ticket for us ? > > Regards > Swathi BN > > *—* > *Swathi Kumar* > Senior Software Engineer > Precisely.com > <https://urldefense.com/v3/__http://www.precisely.com__;!!Ayb5sqE7!q0pGoZbIO1oMWxG_4QUejWvQXc26gHNGigsiz_W_23nIBAyNhNvx3fbmR8Sc87qWDfcO66Eh6jHp8Ah8fMSHcxB5d1TZLg$> > > > ------------------------------ > *From:* Swathi Kumar <[email protected]> > *Sent:* Wednesday, May 6, 2026 10:57 PM > *To:* Lucas Brutschy <[email protected]>; [email protected] < > [email protected]> > *Cc:* Theresa Jackson <[email protected]>; Kathryn Brown < > [email protected]>; Manoj Kumar <[email protected]>; > Aayush Gupta <[email protected]> > *Subject:* Re: Kafka Streams issue > > 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: > 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: > > > - 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 > ------------------------------ > *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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!Ayb5sqE7!q0pGoZbIO1oMWxG_4QUejWvQXc26gHNGigsiz_W_23nIBAyNhNvx3fbmR8Sc87qWDfcO66Eh6jHp8Ah8fMSHcxB82TBjUQ$> > > 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]> > 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. > >
