vamossagar12 commented on PR #13453: URL: https://github.com/apache/kafka/pull/13453#issuecomment-1503125343
Thanks for taking a look @C0urante . I had seen the warnings based on the Java docs and I do agree that the approach taken here is broad. IIUC, [this bit](https://github.com/apache/kafka/blob/17435484e4c49eef440ee412a711a88fed08bf50/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/AbstractHerder.java#L94-L100) talks specifically about the route that's chosen when a connector comes up the first time. I think implicitly, it is describing the workings of the `put` method. Also, the pitfall of the approach `The danger of this approach is that slow starting tasks may cause the status to be overwritten after a rebalance has completed` is somewhat related to this ticket. The other bit about `putSafe` which talks about it being racy is also something this PR tries to address. I do agree that the solution in this PR is a bit broader. Because the JIRA ticket talks about 2 approaches and one of them was specifically about handling just for `RUNNING` and `UNASSIGNED` state. I chose to take this route as it appeared to me that the check doesn't really harm much. I agree we still can't solve all race conditions given the kind of store we are using, but it should reduce some of the race conditions. Regarding the priority, this is something we have noticed internally on our monitoring tools. Having said that, if you are swamped with other things, won't definitely want to burden you anymore! You can get to it whenever you have some time :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
