giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastian Schelter <>
Subject Re: Did GIRAPH-11 break vertex reactivation?
Date Tue, 15 Nov 2011 21:17:59 GMT
Yes, that fixes it. Thank you!


On 15.11.2011 22:12, Avery Ching wrote:
> This should fix it.  It passed local unittests.  Let me know.
> Avery
> On 11/15/11 1:03 PM, Avery Ching wrote:
>> Yes, I think I broke it.  Sorry.  Let me get you a diff to test quickly.
>> Avery
>> On 11/15/11 12:42 PM, Sebastian Schelter wrote:
>>> Hi,
>>> I updated to the latest trunk (after the GIRAPH-11 commit) and wanted to
>>> continue to work on GIRAPH-51 where I use a small toy graph to test
>>> SimpleShortestPathVertex.
>>> Unfortunately my code did not work anymore and I guess I tracked it down
>>> to the fact that vertex that voted to halt are not reacted anymore when
>>> new messages arrive.
>>> In SimpleShortestPathVertex every vertex always votes to halt and only
>>> gets reactivated when a shorter path to it has been found. However my
>>> test run always finished after superstep 0.
>>> I don't know too much about Giraph's internals yet, but my guess is that
>>> the number of sent messages is not tracked correctly anymore. Therefore
>>> giraph finishes the algorithm (as all vertices voted to halt) although
>>> there should still be messages in the pipeline.
>>> I think I tracked it down to this behavior:
>>> GraphMapper declares a variable workerSentMessages = 0 and never
>>> increases it. This variable is given to
>>> BspServiceWorker.finishSuperstep() which writes it to zookeeper and uses
>>> it to compute the GlobalStats afterwards, which are used to decide
>>> whether a new superstep has to be scheduled. As it has never been
>>> increased, the algorithm will always stop when all vertices voted to
>>> halt.
>>> It would be great if someone could confirm/disprove this speculation and
>>> help me to continue work on GIRAPH-51
>>> --sebastian

View raw message