[
https://issues.apache.org/jira/browse/GIRAPH-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Reisman updated GIRAPH-469:
-------------------------------
Attachment: GIRAPH-469-1-eli-idea.patch
This is a sketch of the idea I mentioned above. There is a lot of addition
cleanup inside GraphWorker/GraphMapper that would occur as part of (or after)
this refactor at the function level inside the class. It also leaves in some
explanatory comments and assumes jira472 is already committed :)
If this makes sense as a first step, I can clean this up. It will enable this
portion of the GraphMapper entry point to accept more general, pluggable
cluster frameworks to replace GraphMapper later on without messing with MR
compatibility. There are a number of addition little things I would do to make
this a "cleaner break" if this approach is acceptable to everyone.
So I guess this is a request for comment more than anything. Thanks!
> Cleanup GraphMapper
> -------------------
>
> Key: GIRAPH-469
> URL: https://issues.apache.org/jira/browse/GIRAPH-469
> Project: Giraph
> Issue Type: Improvement
> Reporter: Nitay Joffe
> Assignee: Eli Reisman
> Attachments: GIRAPH-469-1-eli-idea.patch
>
>
> I don't see why we even call a map() method seeing as we are overriding
> run(). We are clearly not particularly "mapreduce-y" so we should make it our
> entry point more clear than a map(). Also I think we should have something
> like a WorkerThread similar to MasterThread and clean up all of this to just
> creare whichever threads the node is assigned roles of.
--
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
