divijvaidya commented on PR #13435:
URL: https://github.com/apache/kafka/pull/13435#issuecomment-1479202476

   Hey @Stephan14 
   
   Thank you for your change. 
   
   First, I would like to clarify the motivation of this change. The current 
code is not unsafe  (please correct me if I am wrong) since the code you are 
changing (`updateStaticMemberAndRebalance()`) is already invoked after 
acquiring a lock on group. See: 
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/coordinator/group/GroupCoordinator.scala#L248
 
   Hence, please update the PR title to, "Add additional safety lock in 
GroupCoordinator when persisting metadata".
   
   Second, do we need to add this additional safety lock for a private method? 
Note that even though it is a re-entrant lock, there is a cost involved in 
checking for a inside a private method. I am of the opinion that if a lock is 
acquired at the public method at the very top, then we don't need to acquire 
re-entrant locks in each of the private methods that it calls. Hence, I don't 
think we should make this change.
   
   However, we should probably add a comment for 
`updateStaticMemberAndRebalance()` that it should be called after acquiring a 
lock on group object.


-- 
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

Reply via email to