hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arinto Murdopo <ari...@gmail.com>
Subject Re: TestRMRestart - app1 and appState refer to the same instance
Date Thu, 15 Nov 2012 08:37:15 GMT
Okay done! Waiting for comments on Jira.

regards,

Arinto Murdopo
European Master in Distributed Computing (EMDC)
Universitat Politècnica de Catalunya · BarcelonaTech, Barcelona, Spain
KTH Royal Institute of Technology, Stockholm, Sweden
Phone: +46 725 548 759



On Thu, Nov 15, 2012 at 6:21 AM, Bikas Saha <bikas@hortonworks.com> wrote:

> Thanks! Please post the comments directly on the JIRA.
>
> Bikas
>
> On 11/14/12 4:17 PM, "Arinto Murdopo" <arinto@gmail.com> wrote:
>
> >Dear all,
> >
> >Refer to YARN-128.full-code-4.patch on Yarn-128 issue, I have these
> >following observations:
> >
> >   1. In *TestRMRestart.java* Line 78, app1 and appState refer to the same
> >   instance because we are using memory to store the states (
> >   MemoryRMStateStore). Therefore, the assert result will always be True.
> >   2. ApplicationState is stored when we invoke MockRM's submitApp method.
> >   More precisely, it is in ClientRMService class, line 266.
> >Interestingly,
> >   the state that we store contains the resource request from client. In
> >this
> >   case, the value of resource request is 200. However, if we wait for
> >some
> >   time, the value will be 1024 (which is the normalized value given by
> >the
> >   Scheduler).
> >   3. Currently our school project is trying to persist the state in
> >   persistent storage, and the assert statement in our modified test class
> >   returns error. Since our storage stores the resource value before
> >updated
> >   by the scheduler.
> >
> >Based on above observations, should we update the persisted memory value
> >with the new value assigned by scheduler?
> >Since we are going to restart both ApplicationMaster and NodeManager when
> >there is failure in ResourceManager, I think the answer is no, we can use
> >the original value requested by user. But I'm not really sure with my own
> >reasoning.. soo.. please comment on it. :) . If the answer is yes, then we
> >should wait until Scheduler updates the resource value before persisting
> >it
> >into the storage.
> >
> >best regards,
> >
> >Arinto Murdopo
> >European Master in Distributed Computing (EMDC)
> >Universitat Politècnica de Catalunya · BarcelonaTech, Barcelona, Spain
> >KTH Royal Institute of Technology, Stockholm, Sweden
> >Phone: +46 725 548 759
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message