hama-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ηλίας Καπουράνης <ikapo...@csd.auth.gr>
Subject Re: Aggregator Problem (?)
Date Sat, 21 Dec 2013 22:52:05 GMT
Hey,

Yeah these two are better because having a vertex halted but being 
aggregated is a bit improper in my opinion.
Will check back again!


Στις 21/12/2013 7:09 μμ, ο/η Anastasis Andronidis έγραψε:
> Hi again,
>
> I send you this link for further info on the subject:
>
> https://issues.apache.org/jira/browse/HAMA-588
>
> The voteToHalt() function is marking the vertex as halted for the next superstep! Not
the current. I agree that we should document this functionality more thoroughly to avoid future
problems.
>
> On the other hand you pin point a very interesting subject. I agree with you that more
cases should be handled like:
>
> 1) voteToStop() : Immediately stop the vertex compute and suppress any further calculations
on top of that. (e.g. aggregation)
> 2) voteToTerminate(): Immediately stop the vertex compute, suppress any further calculations
on top of that and deactivate the vertex so even if any message reaches it, will not come
alive.
>
> I will open a JIRA ticket on the proposal, feel free to comment : ) Thanks in advance!
>
> Cheers,
> Anastasis
>
> On 21 Δεκ 2013, at 12:48 μ.μ., Ηλίας Καπουράνης <ikapoura@csd.auth.gr>
wrote:
>
>> Hey,
>>
>> yeah I know about the corner case. What do you mean the aggregated results from superstep
number 1? Between supersteps, there are the "aggregator" supersteps. And they are like  this:
>> - node superstep No.1
>> - aggregator superstep No.1
>> - node superstep No.2 etc etc
>>
>> So if a node at "node superstep No.1" votes to halt, he shouldn't be included in
the aggregator phase which comes next, right?
>>
>> My question is:
>> why the node gets aggregated if he has voted to halt? Doesn't "vote to halt" mean
that he wants to stop?
>>
>>
>>
>> Στις 20/12/2013 11:35 μμ, ο/η Anastasis Andronidis έγραψε:
>>> Hello,
>>>
>>> what you actually see it is an expected behavior from the aggregators. The results
you are taking in the superstep number 2, are the aggregated results from superstep number
1.
>>>
>>> There is a small corner case though. In superstep 0 the aggregators are off.
This will change on next release.
>>>
>>> Cheers,
>>> Anastasis
>>>
>>> On 20 Δεκ 2013, at 4:48 μ.μ., ikapoura@csd.auth.gr wrote:
>>>
>>>> Hello there,
>>>>
>>>> I am using the Graph API and I have noticed something.
>>>> If a node votes to halt at a superstep, we suppose that he won't be part
of the aggregation phase.
>>>> BUT he is included in the aggregation phase of the next superstep!
>>>>
>>>> To be more precise:
>>>>
>>>> - Imagine we have a graph with 10 nodes.
>>>> - At superstep 1 node K votes to halt.
>>>> - At superstep 2 we check the number of the nodes aggregated and its 10.
(it had to be 9)
>>>> - At superstep 3 we check again the number of the nodes aggregated and then
it is 9! (which is the correct)
>>>>
>>>> This persists only with the aggregators. Node K doesn't work at superstep
2.
>>>>
>>>> Can someone confirm that this is a problem or am i missing something?
>>>> Thanks
>>>>
>>>>
>>


Mime
View raw message