You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "huxihx (Jira)" <ji...@apache.org> on 2020/01/13 01:35:00 UTC
[jira] [Updated] (KAFKA-8881) Measure thread running time precisely
[ 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)