https://bugzilla.wikimedia.org/show_bug.cgi?id=72812
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #5 from [email protected] --- (In reply to Andrew Otto from comment #2) > Ah, this is caused by Ellery's use of kafkacat on stat1002. Yikes! kafkacat not properly creating offset directories is ... well a bug. Kafkacat is fresh, so I figure these kinds of issues are expected. No worries. And the logs are clean right now. However, I am thinking this bug shows three other important things, that should get discussed before closing the bug: * kafkacat can get our kafka (not kafkacat) logs to become unusable. That came somewhat as a surprise to me. Do we expect people to use kafkacat more and we need to guard against noise in the logs, or will kafkacat's use die out (except for debugging) and people use ETL-ed data or kafkatee instead? * kafkacat did not recover. Even if kafkacat does not properly survive the leader re-election, I had expected it to recover at some point. But in the end, it did not recover. This item can be explained away, by seeing that kafkacat really was run in acron, and hence restarting again and again with the faulty offsets. * How comes it happened right after the leader election? The timing matches too well to be a simple coincidence. Did the use af kafkacat really start right at the time we re-elected? Do we know how kafkacat (maybe kafkatee) survives re-elecetions? Hence, re-opening, as I think these three items need more discussion. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
