chia7712 commented on pull request #8657: URL: https://github.com/apache/kafka/pull/8657#issuecomment-679855792
> The second issue is that we hold a group lock while calling joinPurgatory.tryCompleteElseWatch. In this call, it's possible that DelayedJoin.onComplete() will be called. In that case, since the caller holds the group lock, we won't be completing partitionsToComplete in completeDelayedRequests(). @junrao I go through group lock again and it is almost used anywhere :( I'm worry about deadlock caused by current approach so I'd like to address @hachikuji refactor and your approach (separate thread). The following changes are included. 1. ```Partition``` does not complete delayed operations. Instead, it adds those delayed operations to a queue. The callers ought to call the new method ```Partition.completeDelayedActions``` to complete those delayed operations in proper place (to avoid conflicting locking). 1. apple above new method to all callers who need to complete delay operations. 1. ```GroupCoordinator.onCompleteJoin``` is called by ```DelayedJoin``` only but it always held a group lock. To resolve it, we complete delayed requests in a separate thread. @junrao WDYT? ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org