Hello and sorry for my late response, I sending this email so we can plan and confirm further the issues with aggregators.
As far as I understood from the discussion on HAMA-833, we should split the functionality of the aggregators in 2 different kinds: 1) global aggregators -> will aggregate information from every vertex in every superstep, ignoring the fact that a vertex maybe is in a voteToHalt state. 2) private aggregators -> will aggregate information on demand of the user. I also want to confirm that we don't need any other states for vertices like those that proposed in HAMA-833: > 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. One last think, is the issue for skipAggregator() functionality. The idea behind this function was to control the calculation of aggregators. e.g. Let's say we have ab aggregator that is slow because it needs to perform some complex calculations. But we also need to perform this heavy calculation every 4 supersteps. The skipAggregator() method can provide a solution to this problem, by specifically request to skip the aggregation on the next superstep. But, If we implement the private aggregators, we might don't need that feature, as the user will have an absolute control over aggregators. Cheers, Anastasis P.S. the name private aggregator is for the current discussion, if you have any better names, please reply.
