I think we currently implicitly assume that there is at least one
element in the Iterable passed to the combiner. The messaging code only
invokes the combiner only if at least one message for the target vertex
has been sent.

However, we should not rely on implicit implementation details but
explicitly specify the semantics of combiners.

--sebastian

On 09.01.2012 13:29, Claudio Martella wrote:
> Hello list,
> 
> for GIRAPH-45 I'm touching the incoming messages and hit an
> interesting problem with the combiner semantics.
> currently, my code fails testBspCombiner for the following reason:
> 
> SimpleSumCombiner::compute() returns a value even if there are no
> messages in the iterator (in this case it returns 0) and for this
> reason the vertices get activated at each superstep.
> 
> At each superstep, under-the-hood, I pass the combiner for each vertex
> an Iterable, which can be empty:
> 
>     public Iterable<M> getMessages(I vertexId) {
>       Iterable<M> messages = inMessages.getMessages(vertexId);
>       if (combiner != null) {
>               M combinedMsg;
>               try {
>                       combinedMsg = combiner.combine(vertexId, messages);
>               }  catch (IOException e) {
>                       throw new RuntimeException("could not combine", e);
>               }
>               if (combinedMsg != null) {
>                       List<M> tmp = new ArrayList<M>(1);
>                       tmp.add(combinedMsg);
>                       messages = tmp;
>               } else {
>                       messages = new ArrayList<M>(0);
>               }
>       }
>       return messages;
>     }
> 
> the Iterable returned by this methods is passed to
> basicVertex.putMessages() right before the compute().
> Now, the question is: who's wrong? The combiner code that returns a
> sum of 0 over no values, or the framework that calls the combiner with
> 0 messages?
> 
> 
> 

Reply via email to