Return-Path: <hdfs-issues-return-177302-archive-asf-public=cust-asf.ponee.io@hadoop.apache.org>
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 9E1D9200C1A
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Fri,  6 Jan 2017 00:15:00 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id 9D04E160B33; Thu,  5 Jan 2017 23:15:00 +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 EDFC4160B4D
	for <archive-asf-public@cust-asf.ponee.io>; Fri,  6 Jan 2017 00:14:59 +0100 (CET)
Received: (qmail 11306 invoked by uid 500); 5 Jan 2017 23:14:59 -0000
Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:hdfs-issues-help@hadoop.apache.org>
List-Unsubscribe: <mailto:hdfs-issues-unsubscribe@hadoop.apache.org>
List-Post: <mailto:hdfs-issues@hadoop.apache.org>
List-Id: <hdfs-issues.hadoop.apache.org>
Delivered-To: mailing list hdfs-issues@hadoop.apache.org
Received: (qmail 10907 invoked by uid 99); 5 Jan 2017 23:14:58 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2017 23:14:58 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id A258B2C2AB6
	for <hdfs-issues@hadoop.apache.org>; Thu,  5 Jan 2017 23:14:58 +0000 (UTC)
Date: Thu, 5 Jan 2017 23:14:58 +0000 (UTC)
From: "Manoj Govindassamy (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13032383.1483648263000.656331.1483658098661@Atlassian.JIRA>
In-Reply-To: <JIRA.13032383.1483648263000@Atlassian.JIRA>
References: <JIRA.13032383.1483648263000@Atlassian.JIRA> <JIRA.13032383.1483648263559@arcas>
Subject: [jira] [Updated] (HDFS-11296) Maintenance state expiry should be an
 epoch time and not jvm monotonic
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Thu, 05 Jan 2017 23:15:00 -0000


     [ https://issues.apache.org/jira/browse/HDFS-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manoj Govindassamy updated HDFS-11296:
--------------------------------------
    Description: 
Currently it is possible to configure an expiry time in milliseconds for a DataNode in maintenance state. As per the design, the expiry attribute is an absolute time, beyond which NameNode starts to stop the ongoing maintenance operation for that DataNode. Internally in the code, this expiry time is read and checked against {{Time.monotonicNow()}} making the expiry based on more of JVM's runtime, which is very difficult to configure for any external user. The goal is to make the expiry time an absolute epoch time, so that its easy to configure for external users.

{noformat}
{
    "hostName": <host>,
    "port": <port>,
    "adminState": "IN_MAINTENANCE",
    "maintenanceExpireTimeInMS": <time in millis>
}
{noformat}

DatanodeInfo.java
{noformat}
  public static boolean maintenanceNotExpired(long maintenanceExpireTimeInMS) {
    return Time.monotonicNow() < maintenanceExpireTimeInMS;
  }
{noformat}

  was:

Currently it is possible to configure an expiry time in milliseconds for a DataNode in maintenance state. As per the design, the expiry attribute is an absolute time, beyond which NameNode starts to stop the ongoing maintenance operation for that DataNode. Internally in the code, this expiry time is read and checked against {{Time.monotonicNow()}} making the expiry based on more of JVM's runtime, which is very difficult to configure for any external user. The goal is to make the expiry time an absolute epoch time, so that its easy to configure for external users.

{noformat}
{
    "hostName": <host>,
    "port": <port>,
    "adminState": "IN_MAINTENANCE",
    "maintenanceExpireTimeInMS": <time in millis>
}
{noformat}

DatanodeInfo.java
{noformat}
  public static boolean maintenanceNotExpired(long maintenanceExpireTimeInMS) {
    return Time.monotonicNow() < maintenanceExpireTimeInMS;
  }
{noformat}

    Component/s:     (was: datanode)
                     (was: namenode)

> Maintenance state expiry should be an epoch time and not jvm monotonic
> ----------------------------------------------------------------------
>
>                 Key: HDFS-11296
>                 URL: https://issues.apache.org/jira/browse/HDFS-11296
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>    Affects Versions: 3.0.0-alpha1
>            Reporter: Manoj Govindassamy
>            Assignee: Manoj Govindassamy
>         Attachments: HDFS-11296.01.patch
>
>
> Currently it is possible to configure an expiry time in milliseconds for a DataNode in maintenance state. As per the design, the expiry attribute is an absolute time, beyond which NameNode starts to stop the ongoing maintenance operation for that DataNode. Internally in the code, this expiry time is read and checked against {{Time.monotonicNow()}} making the expiry based on more of JVM's runtime, which is very difficult to configure for any external user. The goal is to make the expiry time an absolute epoch time, so that its easy to configure for external users.
> {noformat}
> {
>     "hostName": <host>,
>     "port": <port>,
>     "adminState": "IN_MAINTENANCE",
>     "maintenanceExpireTimeInMS": <time in millis>
> }
> {noformat}
> DatanodeInfo.java
> {noformat}
>   public static boolean maintenanceNotExpired(long maintenanceExpireTimeInMS) {
>     return Time.monotonicNow() < maintenanceExpireTimeInMS;
>   }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org