[
https://issues.apache.org/jira/browse/KAFKA-8881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huxihx updated KAFKA-8881:
--------------------------
Description: Currently, the code uses `System.currentTimeMillis()` to
measure timeout extensively. However, many situations trigger the thread
suspend such as gc and context switch. In such cases, the timeout value we
specify is not strictly honored. I believe many of flaky tests failed with
timed-out are a result of this. Maybe we should use
ThreadMXBean#getCurrentThreadCpuTime to precisely measure the thread running
time. (was: Currently, the code uses `System.currentTimeMillis()` to measure
timeout extensively. However, many situations trigger the thread suspend such
as gc and context switch. In such cases, the timeout value we specify is not
strictly honored. I believe many of flaky tests failed with timed-out are a
result of this. Maybe we should use ThreadMXBean#getCurrentThreadUserTime to
precisely measure the thread running time.)
> Measure thread running time precisely
> -------------------------------------
>
> Key: KAFKA-8881
> URL: https://issues.apache.org/jira/browse/KAFKA-8881
> Project: Kafka
> Issue Type: Improvement
> Affects Versions: 2.4.0
> Reporter: huxihx
> Priority: Major
> Labels: needs-discussion
>
> Currently, the code uses `System.currentTimeMillis()` to measure timeout
> extensively. However, many situations trigger the thread suspend such as gc
> and context switch. In such cases, the timeout value we specify is not
> strictly honored. I believe many of flaky tests failed with timed-out are a
> result of this. Maybe we should use ThreadMXBean#getCurrentThreadCpuTime to
> precisely measure the thread running time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
