Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@giraph.apache.org
Date: Tue, 7 Aug 2012 22:33:10 +0000 (UTC)
From: "Jakob Homan (JIRA)" <jira@apache.org>
To: giraph-dev@incubator.apache.org
Message-ID: <1331431315.1766.1344378790791.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <4192876.36357.1342025854696.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (GIRAPH-246) Periodic worker calls to
 context.progress() will prevent timeout on some Hadoop clusters during
 barrier waits
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/GIRAPH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430690#comment-13430690 ] 

Jakob Homan commented on GIRAPH-246:
------------------------------------

The PredicateLock stuff is fine, but according to Jaeho, doesn't seem to be working.  Once the reason is nailed down, GIRAPH-274 can re-introduce it.
                
> Periodic worker calls to context.progress() will prevent timeout on some Hadoop clusters during barrier waits
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: GIRAPH-246
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-246
>             Project: Giraph
>          Issue Type: Improvement
>          Components: bsp
>    Affects Versions: 0.2.0
>            Reporter: Eli Reisman
>            Assignee: Eli Reisman
>            Priority: Minor
>              Labels: hadoop, patch
>             Fix For: 0.2.0
>
>         Attachments: GIRAPH-246-1.patch, GIRAPH-246-2.patch, GIRAPH-246-3.patch, GIRAPH-246-4.patch, GIRAPH-246-5.patch, GIRAPH-246-6.patch
>
>
> This simple change creates a command-line configurable option in GiraphJob to control the time between calls to context().progress() that allows workers to avoid timeouts during long data load-ins in which some works complete their input split reads much faster than others, or finish a super step faster. I found this allowed jobs that were large-scale but with low memory overhead to complete even when they would previously time out during runs on a Hadoop cluster. Timeout is still possible when the worker crashes or runs out of memory or has other GC or RPC trouble that is legitimate, but prevents unintentional crashes when the worker is actually still healthy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira