Mailing-List: contact dev-help@crunch.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@crunch.apache.org
Date: Fri, 1 Nov 2013 17:09:23 +0000 (UTC)
From: "Josh Wills (JIRA)" <jira@apache.org>
To: crunch-dev@incubator.apache.org
Message-ID: <JIRA.12677106.1383325039356.7657.1383325763839@arcas>
In-Reply-To: <JIRA.12677106.1383325039356@arcas>
References: <JIRA.12677106.1383325039356@arcas>
Subject: [jira] [Commented] (CRUNCH-292) Hack around Hadoop2's job counter
 limits
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Wills commented on CRUNCH-292:
-----------------------------------

@Vinod I just meant that the limits are specified in the Counters library itself (Limits.java, specifically), which the in-memory pipeline uses directly. No YARN/MR issues here, it's easy to get around it on the cluster itself as you indicated.

> Hack around Hadoop2's job counter limits
> ----------------------------------------
>
>                 Key: CRUNCH-292
>                 URL: https://issues.apache.org/jira/browse/CRUNCH-292
>             Project: Crunch
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: Josh Wills
>            Assignee: Josh Wills
>         Attachments: CRUNCH-292.patch
>
>
> Hadoop2 introduces limits in the Counters library that set a maximum of 120 counters per job. These limits are really hard to hack around (for some good reasons); the only real way to override them is to update mapred-site.xml and restart the cluster.
> This presents a challenge for Crunch's in-memory implementation, which uses the Counters library in local mode and can potentially generate well more than 120 counters when testing long pipelines. 


--
This message was sent by Atlassian JIRA
(v6.1#6144)