giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Reisman (JIRA)" <>
Subject [jira] [Commented] (GIRAPH-469) Cleanup GraphMapper
Date Mon, 07 Jan 2013 00:34:12 GMT


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:
>             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:

View raw message