It's not a problem if they use different port numbers. This is good discussion.
BTW, I think, I have to split task into smaller tasks. Sent from my iPad On Jul 11, 2011, at 6:06 PM, "ChiaHung Lin" <[email protected]> wrote: > A bit more questions. > > Suppose the BSPPeer1, on GroomServer A, talks to BSPPeer7 at GroomServer C. > Now when BSPPeer2, also on GroomServer A, wants to synchronize with BSPPeer8. > How will GroomServer C know which peer (e.g. {7,8,9}) to be synchronized with > BSPPeer2 from GroomServer A? > > The current implementation in trunk seems only identify peerName, which > consists of host:port value. Therefore, during the sync() stage, the > outgoingqueue probably would be confused which task/ BSPPeer the message to > be deliver. This potentially might have issue when performing checkpoint. For > checkpointing, the state e.g an incoming message is needed to be saved to > persistent storage so that in the recovery stage, previous state can be > rollback. > > > -----Original message----- > From:Edward J. Yoon <[email protected]> > To:[email protected],[email protected] > Date:Fri, 8 Jul 2011 17:51:05 +0900 > Subject:Re: About HAMA-410 > > Hi, > > Let's assume that BSPPeer1 send a message to BSPPeer7. > > Currently, BSPPeer1 send a message to GroomServerA first, and then > GroomServerA send to GroomServerC. Finally, BSPPeer7 will receive that > message from GroomServerC. > >> From the GroomServer source, it seems that BSPPeer and Task perform >> different roles where Task takes responsibility of task execution and >> BSPPeer in communication (sync, send). What's the benefit of mering two >> different roles into one? > > So again, the communication will be occurred among Invoked (child) > processes directly. BSPPeer1 <-> BSPPeer7. > > P.S., The reason why we don't use the multi-threads inside > GroomServer, is related with killing job/task. > >> How do a BSPPeer distinguish other peers only related to computation itself >> involved in? For instance, each GroomServer has 3 tasks where tasks are >> divided into 3 groups including {1,4,7}, {2,5,8} and {3,6,9}. How do they >> communicate e.g without falsely sync with different peers? > > There's no change. BSPPeer knows all peer names, and barrier will be > managed by ZK. > > On Fri, Jul 8, 2011 at 4:22 PM, ChiaHung Lin <[email protected]> wrote: >> This looks ok from the perspective of executing function. In addition, I >> have a few questions and would like to gain more ideas on how it may work >> after refactored. >> >> From the GroomServer source, it seems that BSPPeer and Task perform >> different roles where Task takes responsibility of task execution and >> BSPPeer in communication (sync, send). What's the benefit of mering two >> different roles into one? >> >> How do a BSPPeer distinguish other peers only related to computation itself >> involved in? For instance, each GroomServer has 3 tasks where tasks are >> divided into 3 groups including {1,4,7}, {2,5,8} and {3,6,9}. How do they >> communicate e.g without falsely sync with different peers? >> >> GroomServerA GroomServerB GroomServerC >> BSPPeer1 BSPPeer4 BSPPeer7 >> BSPPeer2 BSPPeer5 BSPPeer8 >> BSPPeer3 BSPPeer6 BSPPeer9 >> >> -----Original message----- >> From:Edward J. Yoon <[email protected]> >> To:[email protected] >> Date:Thu, 7 Jul 2011 19:48:48 +0900 >> Subject:About HAMA-410 >> >> Hi, >> >> To support multi-tasks, I'm thinking about merging BSPPeer and Task. >> Then, communication will be occurred among Tasks directly. I think, >> there's no need to manage BSPPeers inside GroomServer. >> >> Can we think about the latent side-effects from this decision, together? >> >> Thanks. >> >> -- >> Best Regards, Edward J. Yoon >> @eddieyoon >> >> >> -- >> ChiaHung Lin >> Department of Information Management >> National University of Kaohsiung >> Taiwan >> > > > > -- > Best Regards, Edward J. Yoon > @eddieyoon > > > -- > ChiaHung Lin > Department of Information Management > National University of Kaohsiung > Taiwan
