Yes, that is exactly the way aggregators should be used ;) 2012/11/30 lee fei <[email protected]>
> Hi Thomas, > Beautiful solution! I am wonder if I maintain an aggregator which in > every superstep every lived vertexes can add 1 to it, and the master vertex > check this aggregator in next superstep, if the increment is zero, there > mean no lived vertexes in last superstep. > Due to the sum of lived vertexes in one superstep maybe vary large, > maintain an aggregator can be a more efficient way and save communication's > cost? > > On Sat, Dec 1, 2012 at 1:31 AM, Thomas Jungblut > <[email protected]>wrote: > > > You can get the number of tasks/peers via the BSPPeer object that you can > > obtain inside your vertex via getPeer().getNumPeers(). > > Suraj already told you the overall procedure, but I would consult you to > > use the state machine of a vertex. So computation stops if no message has > > been send and no vertex is active any more. > > In case of a graph you can always send a message to a "master" vertex, > e.G. > > with the ID of 0. Therefore you can send a message to a vertex key with > the > > method sendMessage(V destinationVertexID, M msg). > > > > Good luck! > > > > > > 2012/11/30 Du Zhengjun <[email protected]> > > > > > Yes you are right. I am planning to use the vertex API, and the 'node' > > > imply a vertex in a graph. > > > > > > Sorry for my ambiguous express. > > > > > > Thank you for your quick reply :) > > > > > > > > > On Sat, Dec 1, 2012 at 12:47 AM, Thomas Jungblut > > > <[email protected]>wrote: > > > > > > > Wait a second, can you tell us what kind of API are you using? I > assume > > > you > > > > use the vertex API in the graph package right? > > > > > > > > 2012/11/30 Suraj Menon <[email protected]> > > > > > > > > > Hi lee, > > > > > > > > > > I am assuming 'node' here implies BSP peer. > > > > > > > > > > You would have this feature once I get HAMA-652 ( > > > > > https://issues.apache.org/jira/browse/HAMA-652) working. For now > you > > > can > > > > > do > > > > > something similar to what is done is graph processing. > > > > > Keep sending a vote to halt(message) to every other peers, when you > > > want > > > > to > > > > > halt, until in the next superstep you find that the number of votes > > == > > > > > number of peers. This is a limitation in the current > implementation. > > We > > > > > need all the peers running together and peer.sync won't proceed > until > > > all > > > > > the peers enter and leave the synchronization barrier. Please check > > the > > > > > progress on HAMA-652, it should get fixed in near future. > > > > > > > > > > Thanks, > > > > > Suraj > > > > > > > > > > On Fri, Nov 30, 2012 at 11:05 AM, lee fei <[email protected]> > > wrote: > > > > > > > > > > > Thank you for you help~ > > > > > > > > > > > > I need to know if there is any node active in last superstep > to > > > > > > decide which the sub program should to process in the compute( ) > > > > > function. > > > > > > So if I can get the sum of alive nodes(not halted) in last > > superstep > > > or > > > > > the > > > > > > sum of messages sent in last superstep, I can easily make the > > > decision. > > > > > > > > > > > > Is there a way to do that? > > > > > > > > > > > > On Fri, Nov 30, 2012 at 8:30 PM, Edward <[email protected]> > wrote: > > > > > > > > > > > > > It should be always equal to launched tasks num. Instead, we > can > > > > count > > > > > > > failure tasks num. Why do you need? > > > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > > > > On Nov 30, 2012, at 6:29 PM, lee fei <[email protected]> > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Did hama have record the sum of alive nodes or sum of tasks > in > > > > last > > > > > > > > superstep? Is there a way to get this kinds of values? > > > > > > > > > > > > > > > > Thank you for you attention:D > > > > > > > > > > > > > > > > > > > > > > > > > > > >
