Jakob Homan commented on GIRAPH-64:

The warning is an artifact of our silly names; at the moment there's no way 
around it but it shouldn't cause a problem. I've verified the runner works on 
our clusters here.  Since it's just adding a runner (with small tweaks to how 
zk is dealt with), there shouldn't be the possibility of screwing up the tests 
on a real cluster. 

Is this ready to be committed?
> Create VertexRunner to make it easier to run users' computations
> ----------------------------------------------------------------
>                 Key: GIRAPH-64
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-64
>             Project: Giraph
>          Issue Type: New Feature
>            Reporter: Jakob Homan
>            Assignee: Jakob Homan
>         Attachments: GIRAPH-64-2.patch, GIRAPH-64.patch
> Currently, if a user wants to implement a Giraph algorithm by extending 
> {{Vertex}} they must also write all the boilerplate around the {{Tool}} 
> interface and bundle it with the Giraph jar (or get Giraph on the classpath 
> and playing nice with the implementation).  For example, what is included in 
> the PageRankBenchmark and what Kohei has done: 
> https://github.com/smly/java-Giraph-LabelPropagation  It would be better if 
> we had perhaps a Vertex implementation to be subclassed that already had all 
> the standard Tooling included such that all one had to run would be (assuming 
> the Giraph jar was already on the classpath):
> {noformat}hadoop jar my-awesome-vertex.jar my.awesome.vertex -i jazz_input -o 
> jazz_output -if org.apache.giraph.lib.in.text.adjacency-list.LongDoubleDouble 
> -of org.apache.giraph.lib.out.text.adjacency-list.LongDoubleDouble{noformat} 
> This wouldn't work with every algorithm, but would be useful in a large 
> number of cases.

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