You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Producer correctly recognizes that the topic ID has changed, i.e., the topic was re-created (removed and created with the same name).
Unfortunately, the metadata for the just-recreated topic is never fully processed, and the internal metadata cache in the producer is not updated because when the topic is recreated, the leader epoch is always reset to 0 and this logic prevents the update from happening (f47815b#diff-b5723f3211c0413f28859bb339709d86154050db38ce91a29653c36130981f63R2070-R2082).
Thus in cases where the leader of the recreated topic has changed, the producer app keeps trying to produce messages to the old partition leader and never produces to the new partition leader.
How to reproduce
We use an application written in C# and Confluent.Kafka 2.6.0 (which internally uses librdkafka). In the repro-scenario, the app at the beginning creates or recreates (if the topic already exists) 3000 single-partition topics, after that it starts the producer that keeps producing to these newly-(re)created topics.
Topics are being removed and created before the producer is even instantiated, but since there are multiple brokers (3 in our case) in the cluster, some brokers need more time than others to process the topic removal and re-creation thus they can keep reporting topics with old IDs for some time. That can lead to the producer seeing an old ID (and an old leader) of a topic and then a new ID (and a new leader) afterward, but since the new ID will be with epoch leader reset to 0 it will not be properly digested by the producer (leader epoch is not newer...)
Repro steps:
Create a test cluster consisting of at least 3 brokers
Run the test app for the first time (it creates 3000 topics and happily produces to them)
Stop the test app and run it a second time (it removes existing topics and creates 3000 topics again), but this time the app will fail to produce to some topics because of the reasons mentioned above
@marcin-krystianc Thanks for the report, the implementation of KIP-516 (topic ids) needs to be completed with regards to topic re-creation with same name, there are many fields to reset, among them there's the leader epoch. At the moment it's still needed to restart the clients and avoid relying on automatic handling of topic re-creation.
@marcin-krystianc Thanks for the report, the implementation of KIP-516 (topic ids) needs to be completed with regards to topic re-creation with same name, there are many fields to reset, among them there's the leader epoch. At the moment it's still needed to restart the clients and avoid relying on automatic handling of topic re-creation.
I'm happy to contribute a fix for it, but I would appreciate some guidance.
When I analysed how to approach the problem I came to a conclusion that after detecting the topic id change (https://github.com/confluentinc/librdkafka/blob/master/src/rdkafka_topic.c#L1340-L1357), we should remove the topic from cache & mark the topic as UNKNOWN and run the update procedure again. Thus, it would properly initialise the topic with all its fields and set it state again to EXISTS. What do you think?
Description
Producer correctly recognizes that the topic ID has changed, i.e., the topic was re-created (removed and created with the same name).
Unfortunately, the metadata for the just-recreated topic is never fully processed, and the internal metadata cache in the producer is not updated because when the topic is recreated, the leader epoch is always reset to 0 and this logic prevents the update from happening (f47815b#diff-b5723f3211c0413f28859bb339709d86154050db38ce91a29653c36130981f63R2070-R2082).
Thus in cases where the leader of the recreated topic has changed, the producer app keeps trying to produce messages to the old partition leader and never produces to the new partition leader.
How to reproduce
We use an application written in C# and
Confluent.Kafka 2.6.0
(which internally useslibrdkafka
). In the repro-scenario, the app at the beginning creates or recreates (if the topic already exists) 3000 single-partition topics, after that it starts the producer that keeps producing to these newly-(re)created topics.Topics are being removed and created before the producer is even instantiated, but since there are multiple brokers (3 in our case) in the cluster, some brokers need more time than others to process the topic removal and re-creation thus they can keep reporting topics with old IDs for some time. That can lead to the producer seeing an old ID (and an old leader) of a topic and then a new ID (and a new leader) afterward, but since the new ID will be with epoch leader reset to 0 it will not be properly digested by the producer (
leader epoch is not newer...
)Repro steps:
Parameters:
Logs:
Checklist
2.6.0
3.8.0
debug=..
as necessary) from librdkafkaubuntu:22.04(x64)
The text was updated successfully, but these errors were encountered: