Return-Path: X-Original-To: apmail-giraph-dev-archive@www.apache.org Delivered-To: apmail-giraph-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 81624D6C9 for ; Tue, 11 Sep 2012 19:28:37 +0000 (UTC) Received: (qmail 84716 invoked by uid 500); 11 Sep 2012 19:28:37 -0000 Delivered-To: apmail-giraph-dev-archive@giraph.apache.org Received: (qmail 84583 invoked by uid 500); 11 Sep 2012 19:28:37 -0000 Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@giraph.apache.org Delivered-To: mailing list dev@giraph.apache.org Received: (qmail 84574 invoked by uid 99); 11 Sep 2012 19:28:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2012 19:28:37 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of apache.mailbox@gmail.com designates 209.85.216.180 as permitted sender) Received: from [209.85.216.180] (HELO mail-qc0-f180.google.com) (209.85.216.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2012 19:28:30 +0000 Received: by qcmv28 with SMTP id v28so500108qcm.11 for ; Tue, 11 Sep 2012 12:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XLgfaiWJ1UzQ2ucJ5x7gZdUdZ6AdhZVZ8H4U02HMlDo=; b=hLZRnsyHIQtMOaVOq8TfzlQsT7NfepnYGcehzNVj11tYPATdgUp87o9qA96aoMuKHe g5OoGAwnfFpk04MKcrQVfXXiC2wvqL80FCGXt9DAyApjxeJUUuxbZ9TANy+pC7HpA98e Do8KfOfmakv37V+It5/Nz3WVbhyHcxdRWt2iOBuidF+9MJf0buXN4ZBgSEWUTqQWXgQx aX9H/jzIdIRslacxrezm0iYN3mVEbYij2ZE35gzU/0z9fcTVGdMis2M2gKGeAK/13ZG6 R30H9+cR/U4/Uxd87At8Uz0jtgdiHFa0sEoVyphu6xvr87JG40DKp7qKcJLHH1dVI6SR mwog== MIME-Version: 1.0 Received: by 10.224.221.203 with SMTP id id11mr2493754qab.65.1347391689689; Tue, 11 Sep 2012 12:28:09 -0700 (PDT) Received: by 10.49.15.129 with HTTP; Tue, 11 Sep 2012 12:28:09 -0700 (PDT) In-Reply-To: <1307258955.63057.1347367448894.JavaMail.jiratomcat@arcas> References: <208392305.995.1345819499853.JavaMail.jiratomcat@arcas> <1307258955.63057.1347367448894.JavaMail.jiratomcat@arcas> Date: Tue, 11 Sep 2012 12:28:09 -0700 Message-ID: Subject: Re: [jira] [Commented] (GIRAPH-315) giraph-site.xml isn't read on time From: Eli Reisman To: dev@giraph.apache.org Content-Type: multipart/alternative; boundary=20cf306f78ae09897a04c97213dc --20cf306f78ae09897a04c97213dc Content-Type: text/plain; charset=ISO-8859-1 Interesting. Here's what I know from struggling with GIRAPH-214. Configurations get created with "new" but are populated in constructor by static values stored when the class is loaded and the static addResource() blocks are called on various Hadoop and Giraph config files. Once these are populated, any "new Configuration()" call will be auto-populated with the values read in the static blocks as far as I know. In GiraphRunner, GiraphJob is definitely created before any threads on any mappers are run, master or not. As soon as the GiraphJob class is loaded, the Configuration class already populated with Hadoop constants from its conf files is additionally populated with "giraph-site.xml" values and -D command line opts passed into bin/giraph, and then the Configuration instance with all that data is wrapped in GiraphJob, which is wrapped in GiraphRunner, which is passed to Hadoop for worker/master Mappers to get greated from them when the call to ToolRunner is made at the bottom of GiraphRunner. So we should be good there. However, in various unit tests all of this is done/not done or re-ordered from the above scenario in various ways, and some magic goes on because GiraphRunner inherits Tool. In the tests where we just create a one-off Configuration or one-off GiraphJob, funny stuff might occur. I think this is also why both GiraphRunner and GiraphJob have the static block, to avoid strange chicken-and-egg issues in GiraphRunner's Configuration. Thats about all I know. I am working on a couple patches today but at least one (thanks for the help) is for Giraph and will include getting my home setup running so maybe I can reproduce this and figure out what the deal is. Giraph's interactions with the Hadoop framework have always provided me with many amusing hours of frustration and I expect that relationship to continue ;) On Tue, Sep 11, 2012 at 5:44 AM, Maja Kabiljo (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/GIRAPH-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452974#comment-13452974] > > Maja Kabiljo commented on GIRAPH-315: > ------------------------------------- > > Yes, it is happening, but just in tests. > > Here are a few things I noticed while investigating this, maybe they'll > make more sense to you since you worked a lot with Configuration already. > > For example while in BspCase.setupConfiguration confgurations from other > files (i.e. core-site.xml, mapred-default.xml...) are not visible either, I > guess it looks for them in different folder. > > On master static block of GiraphJob gets called some steps after > MasterThread.run is called (this happens also when running benchmarks and > examples). But it seems like when we execute "hadoop jar ..." it gets > called somewhere before also, not sure where. > > In tests config object has the same resources as the one we get with new > Configuration(), which is otherwise not the case. > > > giraph-site.xml isn't read on time > > ---------------------------------- > > > > Key: GIRAPH-315 > > URL: https://issues.apache.org/jira/browse/GIRAPH-315 > > Project: Giraph > > Issue Type: Bug > > Reporter: Maja Kabiljo > > Assignee: Maja Kabiljo > > Priority: Trivial > > Attachments: GIRAPH-315.patch > > > > > > While running some tests I noticed that on the master I get different > values of some configuration parameters in the beginning of the execution > than later on. It turned out that giraph-site.xml gets added as default > resource a bit later than it should. > > This only happens when running tests. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > --20cf306f78ae09897a04c97213dc--