giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Homan (Commented) (JIRA)" <>
Subject [jira] [Commented] (GIRAPH-52) There should be a scheme to limit the counter
Date Fri, 14 Oct 2011 02:06:13 GMT


Jakob Homan commented on GIRAPH-52:

If you'd like to come up with a way around the limit, this would be the correct JIRA.  Perhaps
just output statistics for the last n iterations? Or every m iteration, skipping enough to
stay under the limit?  One could check for the presence of the conf value with reasonable
certainty that if it's not there this behavior would be appropriate (this isn't full proof
since the value could be set on the server but not the client, but this would work 99% of
the time and an error message, if it doesn't, could suggest that possibility).
> There should be a scheme to limit the counter
> ---------------------------------------------
>                 Key: GIRAPH-52
>                 URL:
>             Project: Giraph
>          Issue Type: Bug
>          Components: mapreduce
>    Affects Versions: 0.70.0
>            Reporter: Zhiwei Gu
>             Fix For: 0.70.0
> For hadoop version above, the cluster-wise configuration mapreduce.job.counters.limit
cannot be overrided, while the superstep iterations is not deterministic, the job might run
several hundreds or even thousand of supersteps, it will always kill the job. This will limit
the usage of Giraph and is tooooo bad.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message