[
https://issues.apache.org/jira/browse/GIRAPH-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545536#comment-13545536
]
Eli Reisman commented on GIRAPH-469:
------------------------------------
Looking at GraphMapper a bit more, perhaps I have this idea backwards.
Since we can only do single inheritance in Java, and since the GraphMapper (or
its future equivalent) must inherit Mapper<O,O,O,O> to stay compatible with
MRv1, perhaps the thing to do here is encapsulate the Giraph-centric business
logic in a new utility class, let each GraphMapper own one of those, and call
its methods to do the Giraph work. This is a bit more confusing for those who
want to implement alternate GraphMapper-type classes but allows future
framework-glue classes like a "pure YARN" equivalent to GraphMapper do Giraph's
business without duplicating that code, and allows GraphMapper to keep
inheriting from Mapper without all future framework impl's doing the same.
I'm playing with an idea for this, might throw a patch up to better describe
what i'm talking about and see what you think? Is there a better way to handle
the required legacy inheritance from Mapper?
> 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
>
> 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
