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 μ.μ., Ηλίας Καπουράνης <[email protected]> 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 μ.μ., [email protected] 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
