Maciej Mensfeld
Maciej Mensfeld
Kafka logs from the moment of the hanging assignment: ``` kafka | [2024-07-17 12:00:52,235] INFO [GroupCoordinator 1]: Dynamic member with unknown member id joins group eabcf19b-efb8-4f5f-8598-faf7cacb4dd1 in PreparingRebalance state. Created...
What is SUPER interesting to me, is the fact that this does not happen if I set `client.id` as follows (timestamps): ``` "1721229018.5395756" "1721229018.539616" "1721229018.539644" "1721229018.5396647" "1721229018.5396793" "1721229018.5397322" "1721229023.5395145" "1721229028.5397005"...
One more update: I wanted to check if this isn't a Kafka issue with how it caches (incorrectly) some of the metadata responses but with RedPanda librdkafka presents the same...
@emasab you are welcome. Can you explain to me why was it mitigated by client id randomization?
@emasab do you have an ETA for this maybe? Just a PR would help me because I could temporarily cherry-pick this and release as a special release for ppl affected...
this seems to work ``` --- rdkafka_sticky_assignor.c 2024-07-08 09:47:43.000000000 +0200 +++ rdkafka_sticky_assignor_m.c 2024-07-30 09:44:38.529759640 +0200 @@ -769,7 +769,7 @@ const rd_kafka_topic_partition_list_t *partitions; const char *consumer; const rd_map_elem_t *elem; - int...
@p4block any findings on that? same isue
@p4block thanks, I for now just move by 1 cm each 2h which seems to mitigate this.
patching has been merged
superseeds https://github.com/karafka/rdkafka-ruby/issues/476