max.poll.intervals.msはデフォルトでint.Maxに設定されています
Apache Kafkaドキュメントの状態：
内部Kafka Streamsコンシューマのmax.poll.interval.msのデフォルト値が300000からInteger.MAX_VALUEに変更されました
この値は、レコードのバッチの処理時間が特定のしきい値を超えたことを検出するために使用されるので、そのような「無制限」の値に理由はありますか？
アプリケーションが応答しなくなることはありますか？またはKafka Streamsには、処理に時間がかかりすぎるときにコンシューマグループを離れる別の方法がありますか？
アプリケーションが応答しなくなることはありますか？またはKafka Streamsには、処理に時間がかかりすぎるときにコンシューマグループを離れる別の方法がありますか？
Kafka Streamsは、このコンテキストのKafkaコンシューマクライアントのハートビート機能を利用して、ハートビート（「このアプリインスタンスはまだ生きているか？」）をpoll()への呼び出しから切り離します。 2つの主要なパラメーターはsession.timeout.ms（ハートビートスレッド用）およびmax.poll.interval.ms（処理スレッド用）、およびその違いは https://stackoverflow.com/a/39759329/174358 で詳しく説明されています。
ハートビートが導入されたのは、アプリケーションインスタンスが「進行していない」と見なされずに「死んでいる」と見なされずにレコードの処理に多くの時間を費やすことができるようにするためです。たとえば、アプリは1分間1つのレコードに対して多くの処理を実行しながら、Kafka "Hey、I'm still alive、and Iam進歩しています。しかし、まだ処理は完了していません。しばらくお待ちください。」
もちろんmax.poll.interval.msのデフォルト（Integer.MAX_VALUE）たとえば、ポーリングレコードの間にX秒より長い時間がかかり、したがってX秒より長い時間がかかる場合に、アプリインスタンスが実際に「デッド」と見なされるようにする場合は、低い設定に最新のラウンド。そのような構成が理にかなっているかどうかは、特定のユースケースに依存します。ほとんどの場合、デフォルト設定は安全策です。
session.timeout.ms：Kafkaのグループ管理機能を使用するときに、コンシューマーの障害を検出するために使用されるタイムアウト。コンシューマは定期的にハートビートを送信して、ブローカにその活性を示します。このセッションタイムアウトの期限が切れる前にブローカーがハートビートを受信しない場合、ブローカーはこのコンシューマーをグループから削除し、リバランスを開始します。値は、group.min.session.timeout.msおよびgroup.max.session.timeout.msによってブローカー構成で構成された許容範囲内である必要があることに注意してください。
max.poll.interval.ms：コンシューマグループ管理を使用する場合のpoll（）の呼び出し間の最大遅延。これにより、より多くのレコードをフェッチする前にコンシューマーがアイドル状態でいられる時間の上限が設定されます。このタイムアウトの期限が切れる前にpoll（）が呼び出されない場合、コンシューマーは失敗したと見なされ、グループは別のメンバーにパーティションを再割り当てするためにリバランスします。