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
