Hello! Thank you for the KIP. I would like to summarise my understanding of the problem in case I am wrong.
Currently a long-running client refreshes their metadata from a set of brokers obtained when first contacting the cluster. If they have been “away” for too long those brokers might have all changed and upon trying to refresh the metadata the client will fail because it cannot find an available broker. What you propose is that whenever such a situation is encountered the client should try to get the new set of brokers by communicating with the bootstrap-servers again. If I have understood this correctly, then I agree with what is proposed as a solution in this KIP. To answer your question, in my opinion this behaviour should not be guarded by a configuration and should be the default once implemented. As a customer of Kafka, I cannot think of a situation where I would prefer my clients to give up if they have stale data without even trying to get the latest information. As far as I understand, the new behaviour will be entirely constrained to the client code which makes this change easier. As a starting point can we confirm that this is indeed the current behaviour either by a reproducible manual test or by a branch with a failing unit/integration test? Best, Christo > On 18 Jan 2023, at 12:07, 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
