I'll commit that patch. Then, we have to remove of the size limit of tasks per groom and test. (Recently, I'm learning maven :P)
TRUNK can be improved or reverted back anytime if there's some problem. On Tue, Jul 12, 2011 at 2:43 PM, Thomas Jungblut <[email protected]> wrote: > BTW, I think, I have to split task into smaller tasks. >> > It would be great if you can do this, I'd really like to do some tasks. But > I don't want to force you to merge everything together, since you've already > made a lot in your patch. > > > 2011/7/12 Edward J. Yoon <[email protected]>: >> 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 >> > > > > -- > Thomas Jungblut > Berlin > > mobile: 0170-3081070 > > business: [email protected] > private: [email protected] > -- Best Regards, Edward J. Yoon @eddieyoon
