Jakob Homan commented on GIRAPH-100:

Please avoid formatting changes as part of code change patches.  They blow up 
the size of the patch and introduce a lot of "what's the difference between 
these lines? Did anything change that needs to be reviewed?"  For instance, 
most of the changes in SimpleCheckpointVertex appear to be spurious.

* What's the point of the changes in TextVertexInputFormat method visibility? 
Are they related to this patch?
* We're throwing a lot of Stringly typed exceptions. For more robust error 
handling and recovery, it may be good to strongly type these instead.
* re: SuperstepHashPartitionerFactory. Moving it out of test and into the 
example directory seems a bit counterproductive to me.  It's a pathological 
implementation; wouldn't it be better to provide a more useful example, rather 
than one that's explicitly not meant to be used?

> Data input sampling and testing improvements
> --------------------------------------------
>                 Key: GIRAPH-100
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-100
>             Project: Giraph
>          Issue Type: New Feature
>          Components: graph
>            Reporter: Avery Ching
>            Assignee: Avery Ching
>         Attachments: GIRAPH-100.patch
> It would be really nice to help debug an application by limiting the input 
> data (% of input splits, max vertices per input split).  Also, it would be 
> nice for the workers to provide a little more debugging info on how far along 
> they are with processing the input data.

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