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: https://issues.apache.org/jira/browse/GIRAPH-52
>             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: 
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to