Aggregators and voteToHalt()

[Anastasis Andronidis <an...@hotmail.com>]

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

Re: Aggregators and voteToHalt()

["Edward J. Yoon" <ed...@apache.org>]

In my opinion, it will causes confusion.

When user need one aggregator, user should choose one of old
setAggregatorClass and new registerCustomAggregator. Then, what's
different between them?

Since new aggregate() interface is work only when vertex is active, I
originally wanted to keep the default aggregator as a aggregator of
entire vertices' values.

I attach my previous opinion again: "my question was, "how can we get
the historical minimum value in each superstep?" or "how can we get
the average or sum value of entire vertices?". It's impossible without
aggregation of entire (active and inactive) vertices' values. BTW, I
just noticed that Giraph provides two types of aggregator behaviour;
regular and persistent."



On Tue, Jan 7, 2014 at 1:47 AM, Tommaso Teofili
<to...@gmail.com> wrote:
> 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 <ed...@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
>> <an...@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 <ed...@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
>> >> <an...@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
>>



-- 
Best Regards, Edward J. Yoon
@eddieyoon

Re: Aggregators and voteToHalt()

[Tommaso Teofili <to...@gmail.com>]

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 <ed...@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
> <an...@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 <ed...@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
> >> <an...@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
>

Re: Aggregators and voteToHalt()

["Edward J. Yoon" <ed...@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
<an...@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 <ed...@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
>> <an...@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

Re: Aggregators and voteToHalt()

[Anastasis Andronidis <an...@hotmail.com>]

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 <ed...@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
> <an...@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
> 

Re: Aggregators and voteToHalt()

["Edward J. Yoon" <ed...@apache.org>]

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
<an...@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