surely having such a behavior being configurable is the best option but I think the default one should be the current behavior as it doesn't make sense (to me) to aggregate data for halted vertices (and as far as I know in line with Pregel design). My 2 cents, Tommaso
2014/1/6 Edward J. Yoon <edwardy...@apache.org> > > Oh, we are going to delete the previous aggregators entirely? > > Yes. Using registerAggregator(), one or two more aggregators can be > used. We don't need to keep hard-coded old aggregator. > > On Mon, Jan 6, 2014 at 11:21 PM, Anastasis Andronidis > <andronat_...@hotmail.com> wrote: > > Oh, we are going to delete the previous aggregators entirely? I thought > we are keeping the old way and also add the new aggregators on top. > > > > On 6 Ιαν 2014, at 3:05 μ.μ., Edward J. Yoon <edwardy...@apache.org> > wrote: > > > >> We don't need to think about it if we introduce new aggregators > >> interface - HAMA-838 - and get rid of hard-coded aggregator in > >> GraphJobRunner. The getAggregatedValue() just returns the aggregated > >> values from S - 1. > >> > >> As I mentioned before, Giraph provides two types of aggregator > >> behaviour; regular (reset for every step) and persistent. We should > >> think about it. > >> > >> On Mon, Jan 6, 2014 at 10:40 PM, Anastasis Andronidis > >> <andronat_...@hotmail.com> wrote: > >>> Hello, > >>> > >>> I want to make it straight about this issue. When a vertex is calling > voteToHalt() do we aggregated at the same superstep? > >>> > >>> The current behavior is: > >>> > >>> superstep1: > >>> vertex -> voteToHalt > >>> Is aggregated just right after. > >>> > >>> superstep2: > >>> vertex -> is halted from previous superstep > >>> Is not aggregated. > >>> > >>> Do we want to aggregate everything no mater if they are halted? Do we > want to stop aggregation right after halting? Or it is ok as it is? > >>> > >>> Cheers, > >>> Anastasis > >> > >> > >> > >> -- > >> Best Regards, Edward J. Yoon > >> @eddieyoon > >> > > > > > > -- > Best Regards, Edward J. Yoon > @eddieyoon >
