Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 078E3200B66 for ; Thu, 18 Aug 2016 13:01:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 06623160ABF; Thu, 18 Aug 2016 11:01:22 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 7E151160AAB for ; Thu, 18 Aug 2016 13:01:21 +0200 (CEST) Received: (qmail 21416 invoked by uid 500); 18 Aug 2016 11:01:20 -0000 Mailing-List: contact issues-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list issues@flink.apache.org Received: (qmail 21382 invoked by uid 99); 18 Aug 2016 11:01:20 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Aug 2016 11:01:20 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 7D4862C02A1 for ; Thu, 18 Aug 2016 11:01:20 +0000 (UTC) Date: Thu, 18 Aug 2016 11:01:20 +0000 (UTC) From: "Stephan Ewen (JIRA)" To: issues@flink.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (FLINK-4423) Introduce a Clock utility for monotonous system timestamps MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 18 Aug 2016 11:01:22 -0000 Stephan Ewen created FLINK-4423: ----------------------------------- Summary: Introduce a Clock utility for monotonous system timestamps Key: FLINK-4423 URL: https://issues.apache.org/jira/browse/FLINK-4423 Project: Flink Issue Type: Sub-task Reporter: Stephan Ewen I suggest to introduce a {{Clock}} class that provides a {{currentTimeMillis()}} function that calls {{System.currentTimeMillis()}} but also remembers the max returned timestamp so far. That way it would never return decreasing timestamps. In the presence of clock backwards adjustments, the appearance would be that time stands still for a while, until the clock has caught up with the previous timestamp. Since we don't rely on this for measuring timeouts, but only for logging / visualization / etc (see [FLINK-4422]) it should not mess up any distributed system behavior. We would use this in places like the {{ExecutionGraph}}, where we record timestamps for state transitions. That way, the utilities that derive charts and times from the status timestamps would not be thrown off if timestamps were decreasing when expected increasing. The same holds for ingestion time timestamps and for processing time triggers. NOTE: I would like some other opinions on that - it is a somewhat delicate matter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)