Hi Philip and all, > if you don't use the client for a long time, why can't you just close the client and re-instantiate a new one when needed? I'm not familiar with the stream thread, so I don't know if that's possible.
Yes, it's always possible to recreate the client (I think, it's the main workaround for this issue). Streams don't do this currently. If we do the fix on the Streams level (catch and recreate the client), it solves the problem there, but it remains unsolved fundamentally and it will be still necessary to do the same fix in other applications. > Another idea here is, would it make sense to expose a maybeUpdateMetadata() API to serve such a purpose? Could you please elaborate, what exactly this function should do? Best, Ivan On Tue, 24 Jan 2023 at 00:33, Philip Nee <philip...@gmail.com> wrote: > Hey Ivan, > > Thanks for the KIP. Some questions for clarification: It seems like the > main problem is that if we don't poll frequently enough, the cluster > topology can change entirely before the metadata is refreshed and thus > causing staled clients. My question is: if you don't use the client for a > long time, why can't you just close the client and re-instantiate a new one > when needed? I'm not familiar with the stream thread, so I don't know if > that's possible. Another idea here is, would it make sense to expose a > maybeUpdateMetadata() API to serve such a purpose? > > Thanks, > P > > > On Wed, Jan 18, 2023 at 4:07 AM Ivan Yurchenko <ivan0yurche...@gmail.com> > wrote: > > > Hello! > > I would like to start the discussion thread on KIP-899: Allow clients to > > rebootstrap. > > This KIP proposes to allow Kafka clients to repeat the bootstrap process > > when fetching metadata if none of the known nodes are available. > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-899%3A+Allow+clients+to+rebootstrap > > > > A question right away: should we eventually change the default behavior > or > > it can remain configurable "forever"? The latter is proposed in the KIP. > > > > Thank you! > > > > Ivan > > >
