Claudio Martella commented on GIRAPH-10:
Yes, this is actually quite the point.
1) you may want to see the different values of your aggregators at different
supersteps (for debugging reasons, just to mention the most obvious). On the
other side, once you're debugged or for performance reason, you just may want
to see the final result and avoid useless I/O.
2) for Aggregators by type we mean a Map<AggregatorType, AggregatorWriter>, so
you can have a fine-grained aggregator writer for each type. You may want a
different persistence depending on the type.
I think it makes sense to let the user decide how often they may be persisted,
and the easiest way i was thinking about is the logic of the checkpointing
frequency parameter. I was going to implement it that way.
About AggregatorWriter being an interface, they idea of having a default
implementation is just to let the user have something that prints the values
without needing to implement it. It makes sense. If the default behavior is not
what he wants, he's free to implement his type. I can also see on the other
side the AggregatorWriter to be a type to be extended by the user (or something
even abstract, like we're doing with WorkerContext). I was expecting to have a
more clear view once writing the code.
> Aggregators are not exported
> Key: GIRAPH-10
> URL: https://issues.apache.org/jira/browse/GIRAPH-10
> Project: Giraph
> Issue Type: New Feature
> Reporter: Avery Ching
> Priority: Minor
> Currently, aggregator values cannot be saved after a Giraph job. There
> should be a way to do this.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira