[
https://issues.apache.org/jira/browse/FLINK-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889714#comment-15889714
]
ASF GitHub Bot commented on FLINK-4422:
---------------------------------------
Github user jinmingjian commented on a diff in the pull request:
https://github.com/apache/flink/pull/3420#discussion_r103627979
--- Diff:
flink-connectors/flink-connector-kafka-0.8/src/main/java/org/apache/flink/streaming/connectors/kafka/internals/KillerWatchDog.java
---
@@ -42,12 +42,12 @@
@SuppressWarnings("deprecation")
@Override
public void run() {
- final long deadline = System.currentTimeMillis() + timeout;
+ final long deadline = System.nanoTime() + timeout * 1_000_000L;
long now;
- while (toKill.isAlive() && (now = System.currentTimeMillis()) <
deadline) {
+ while (toKill.isAlive() && (now = System.nanoTime()) <
deadline) {
try {
- toKill.join(deadline - now);
+ toKill.join((deadline - now) / 1_000_000L);
--- End diff --
thanks for pointing this, my mistake for ignoring the API of Thread#join:)
I proposed a simple move of rounding.
It is found that the Thread#join is using the System.currentTimeMillis().
So the fix may be not as strong as we expected. The better may be that we do
not fix KillerWatchDog because the "last resort" codes already there.
> Convert all time interval measurements to System.nanoTime()
> -----------------------------------------------------------
>
> Key: FLINK-4422
> URL: https://issues.apache.org/jira/browse/FLINK-4422
> Project: Flink
> Issue Type: Sub-task
> Components: Core
> Reporter: Stephan Ewen
> Assignee: Jin Mingjian
> Priority: Minor
>
> In contrast to {{System.currentTimeMillis()}}, {{System.nanoTime()}} is
> monotonous. To measure delays and time intervals, {{System.nanoTime()}} is
> hence reliable, while {{System.currentTimeMillis()}} is not.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
