[jira] [Updated] (HAMA-788) Graph Aggregator Restracturing

["Edward J. Yoon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HAMA-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edward J. Yoon updated HAMA-788:
--------------------------------

    Fix Version/s:     (was: 0.6.3)
    
> Graph Aggregator Restracturing
> ------------------------------
>
>                 Key: HAMA-788
>                 URL: https://issues.apache.org/jira/browse/HAMA-788
>             Project: Hama
>          Issue Type: New Feature
>          Components: graph
>    Affects Versions: 0.6.2
>            Reporter: Anastasis Andronidis
>            Assignee: Anastasis Andronidis
>            Priority: Minor
>              Labels: features
>
> I think that we should add a second type of aggregators that will be able to act on top of BSP peers instead of vertices. This will give the advantage to graph framework programmers and users to add features easier.
> The interface that I was thinking:
> // This will run on slave peers
> // Get the value of the peer we want to monitor and act on it
> public Writable getPeerValue(GraphJobRunner<V, E, M> graphJobRunner);
> // This will run on master aggregator
> // Compose values
> public void aggregate(Writable v);
> // Get the composed value
> public Writable getValue();
> // This will run on slave peers
> // Set the composed value to the peer
> public void setPeer(GraphJobRunner<V, E, M> graphJobRunner, Writable v);
> // Reset the instance so we don't need to recreate object
> public void reset();
> e.g. 
> 1) The graph framework "stop" condition can act as a peer aggregator
>       a) we check on every peer if we have vertex changes (an int variable)
>       b) send all integers to the master aggregator and check if we need to stop
>       c) slaves get a message to stop the peer or continue
> 2) Count all vertices in every superstep (if we have dynamic changes in vertices) can act as a peer aggregator
>       a) get the number of vertices on every peer
>       b) sum all vertices count on master aggregator
>       c) slaves update their values
> For aggregators to work properly, we need to make a sync (superstep) before every graph iteration. But we can also introduce a "lazy" way to do the aggregations so the user code run at same time of the aggregation. (the "stop" condition works this way).

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