Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 137B111A78 for ; Tue, 20 May 2014 01:54:51 +0000 (UTC) Received: (qmail 24142 invoked by uid 500); 20 May 2014 01:54:47 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 24004 invoked by uid 500); 20 May 2014 01:54:47 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 23996 invoked by uid 99); 20 May 2014 01:54:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 01:54:47 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_IMAGE_ONLY_32,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sshi@gopivotal.com designates 209.85.192.52 as permitted sender) Received: from [209.85.192.52] (HELO mail-qg0-f52.google.com) (209.85.192.52) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 01:54:43 +0000 Received: by mail-qg0-f52.google.com with SMTP id a108so10051430qge.25 for ; Mon, 19 May 2014 18:54:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7fZxelIagA6kZxn4RmYX5fiwzhtvUE3jERpc0XS6hNc=; b=G01yVjTjQGU6H+fMgZEdWQEOpGfKIMIFjiB31nFuk4/blzT6ld57LCZKZg7PwY7/Dw GcTINmzdJoYz0XJXsh/lO6Lh4D131LydfVrXUkt+juTsyZlsGbZxyoGu65xC3TFZ6u4f TPJYuIzwhEzTFCZt0OcjdGok5D9aX4oq0A7cPEcCoNCyaUx5HViTDD5SP6v1VhvNx9ox yfmyp6Y8VI9Wja0TXkfbh6QodiRK9O0HvJkyhrB7nFQxSJiQVyClToEuVfmFsf3u5YMu Bn7oW3SKkLf4cfIXI1HSthSicCUVWQgDtn8VqqQabydR/0us1mSA8faQUHHa0j6XlAqU 8tzA== X-Gm-Message-State: ALoCoQlBAVBWstwWRCEpQeNnIgimjdur6jGNSNo0/t2058Sj9PgLU8/LwK3V9CRvBctkdbVkf+Jp MIME-Version: 1.0 X-Received: by 10.140.36.105 with SMTP id o96mr51999395qgo.25.1400550857578; Mon, 19 May 2014 18:54:17 -0700 (PDT) Received: by 10.140.94.146 with HTTP; Mon, 19 May 2014 18:54:17 -0700 (PDT) In-Reply-To: <1400509457.37204.YahooMailNeo@web121901.mail.ne1.yahoo.com> References: <1400509457.37204.YahooMailNeo@web121901.mail.ne1.yahoo.com> Date: Tue, 20 May 2014 09:54:17 +0800 Message-ID: Subject: Re: Container request with short hostname vs full hostname issue From: Stanley Shi To: "user@hadoop.apache.org" , REYANE OUKPEDJO Content-Type: multipart/alternative; boundary=001a11c173345b30f904f9cb287a X-Virus-Checked: Checked by ClamAV on apache.org --001a11c173345b30f904f9cb287a Content-Type: text/plain; charset=UTF-8 To my understanding, resource manager(RM) only knows the current active host by its "long" name; if a host is not seen, it will assume it is not active NOW. when RM sees a short name, it doesn't know this is a short name for some long name so it will not assign it to any node; but instead it will wait for some other hosts to register as the short name (which will not happen); Regards, *Stanley Shi,* On Mon, May 19, 2014 at 10:24 PM, REYANE OUKPEDJO wrote: > There seems to be an issue with the container request when specifying the > host name for the container. We recently tested and verify that a container > request with short host name does not work, the Rresource Manager will > accept the request and will never issue a container for that request. Also > it will not tell there is an issue with the host name of the machine. When > the container request specifies the long host name , it will issue a > container for that request. Is there any requirement that the each > container request that specifies the hostname should use a full host name > ? If yes what is the reason for this ? > > > Thank you. > > > Reyane OUKPEDJO > > --001a11c173345b30f904f9cb287a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To my understanding, resource manager(RM) only knows = the current active host by its "long" name; if a host is not seen= , it will assume it is not active NOW.
when RM sees a short name, = it doesn't know this is a short name for some long name so it will not = assign it to any node; but instead it will wait for some other hosts to reg= ister as the short name (which will not happen);

Regards,
Stanley Shi,



On Mon, May 19, 2014 at 10:24 PM, REYANE= OUKPEDJO <r.oukpedjo@yahoo.com> wrote:
=
There seems to be an issue with the container request when specifying = the host name for the container. We recently tested and verify that a conta= iner request with short host name does not work, the Rresource Manager will= accept the request and will never issue a container for that request. Also= it will not tell there is an issue with the host name of the machine. When= =C2=A0the container request specifies the long host name , it will issue a= container for that request. Is there any requirement that the each contain= er request that specifies the hostname should use a full host =C2=A0name ? = If yes what is the reason for this ?


Thank you.


Reyane OUKPEDJO


--001a11c173345b30f904f9cb287a--