chia7712 commented on a change in pull request #8657:
URL: https://github.com/apache/kafka/pull/8657#discussion_r483897245
##########
File path:
core/src/test/scala/unit/kafka/coordinator/AbstractCoordinatorConcurrencyTest.scala
##########
@@ -201,8 +201,8 @@ object AbstractCoordinatorConcurrencyTest {
}
}
val producerRequestKeys =
entriesPerPartition.keys.map(TopicPartitionOperationKey(_)).toSeq
- watchKeys ++= producerRequestKeys
producePurgatory.tryCompleteElseWatch(delayedProduce,
producerRequestKeys)
+ watchKeys ++= producerRequestKeys
Review comment:
> will thread_3's attempt for getting the readLock blocked after
thread_2?
To the best of my knowledge, writers have preference over readers in order
to avoid starvation. That behavior is not public and we can get some evidence
from source code. for example:
```java
final boolean readerShouldBlock() {
/* As a heuristic to avoid indefinite writer starvation,
* block if the thread that momentarily appears to be head
* of queue, if one exists, is a waiting writer. This is
* only a probabilistic effect since a new reader will not
* block if there is a waiting writer behind other enabled
* readers that have not yet drained from the queue.
*/
return apparentlyFirstQueuedIsExclusive();
}
```
At any rate, the non-fair mode does not guarantee above situation does not
happen. Hence, it would be better to avoid potential deadlock caused by
```tryCompleteElseWatch```.
> I think we still need operation.safeTryComplete in
DelayedOperation.tryCompleteElseWatch()
How about using ```tryLock``` in tryCompleteElseWatch? It avoids conflicting
locking and still check completion of delayed operations after adding watches?
----------------------------------------------------------------
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
