Re: [DISCUSS] Official Docker Image at release time

[Tsuyoshi Ozawa]

Forwarding this discussion to Klaus.

- Tsuyoshi

On Tue, Jul 19, 2016 at 4:46 PM, Tsuyoshi Ozawa  wrote:
> Hi developers,
>
> Klaus mentioned the availability of an official docker image of Apache
> Hadoop. Is it time that we start to distribute an official docker
> image at release time?
>
> http://mail-archives.apache.org/mod_mbox/hadoop-user/201607.mbox/%3CSG2PR04MB162977CFE150444FA022510FB6370%40SG2PR04MB1629.apcprd04.prod.outlook.com%3E
>
> Thoughts?
>
> Thanks,
> - Tsuyoshi

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Resolved] (YARN-3927) Make the NodeManager's ContainerManager pluggable

[Subru Krishnan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/YARN-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Subru Krishnan resolved YARN-3927.
--
Resolution: Workaround

We ended up adding AMRMProxy as a first class service in NM.

> Make the NodeManager's ContainerManager pluggable
> -
>
> Key: YARN-3927
> URL: https://issues.apache.org/jira/browse/YARN-3927
> Project: Hadoop YARN
>  Issue Type: Sub-task
>  Components: nodemanager
>Reporter: Subru Krishnan
>Assignee: Subru Krishnan
>
> YARN-2884 proposes proxying all AM-RM communication for:
>   * perform distributed scheduling decisions (YARN-2877)
>   * throttling mis-behaving AMs
>   * mask the access to a federation of RMs (YARN-2915)
> To enable all of the above, we are implementing the AMRMProxy as an extension 
> to NM's ContainerManagerImpl.This JIRA is for making the ContainerManager 
> pluggable so that we allow dynamically swap in of the AMRMProxy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5413) Create a proxy chain for ResourceManager Admin API in the Router

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5413:


 Summary: Create a proxy chain for ResourceManager Admin API in the 
Router
 Key: YARN-5413
 URL: https://issues.apache.org/jira/browse/YARN-5413
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan


As detailed in the proposal in the umbrella JIRA, we are introducing a new 
component that routes client request to appropriate ResourceManager(s). This 
JIRA tracks the creation of a proxy for ResourceManager Admin API in the 
Router. This provides a placeholder for:
1) throttling mis-behaving clients (YARN-1546)
3) mask the access to multiple RMs (YARN-3659)

We are planning to follow the interceptor pattern like we did in YARN-2884 to 
generalize the approach and have only dynamically coupling for Federation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5412) Create a proxy chain for ResourceManager REST API in the Router

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5412:


 Summary: Create a proxy chain for ResourceManager REST API in the 
Router
 Key: YARN-5412
 URL: https://issues.apache.org/jira/browse/YARN-5412
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan
Assignee: Giovanni Matteo Fumarola


As detailed in the proposal in the umbrella JIRA, we are introducing a new 
component that routes client request to appropriate ResourceManager(s). This 
JIRA tracks the creation of a proxy for ResourceManager REST API in the Router. 
This provides a placeholder for:
1) throttling mis-behaving clients (YARN-1546)
3) mask the access to multiple RMs (YARN-3659)

We are planning to follow the interceptor pattern like we did in YARN-2884 to 
generalize the approach and have only dynamically coupling for Federation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5411) Create a proxy for ApplicationClientProtocol in the Router

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5411:


 Summary: Create a proxy for ApplicationClientProtocol in the Router
 Key: YARN-5411
 URL: https://issues.apache.org/jira/browse/YARN-5411
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan
Assignee: Giovanni Matteo Fumarola


As detailed in the proposal in the umbrella JIRA, we are introducing a new 
component that routes client request to appropriate ResourceManager(s). This 
JIRA tracks the creation of a proxy for ApplicationClientProtocol in the Router.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5410) Bootstrap Router module

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5410:


 Summary: Bootstrap Router module
 Key: YARN-5410
 URL: https://issues.apache.org/jira/browse/YARN-5410
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan
Assignee: Giovanni Matteo Fumarola


As detailed in the proposal in the umbrella JIRA, we are introducing a new 
component that routes client request to appropriate ResourceManager(s). This 
JIRA tracks the creation of a new sub-module for the Router.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Resolved] (YARN-5381) fix NPE listing wildcard directory on Windows

[Haibo Chen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/YARN-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Haibo Chen resolved YARN-5381.
--
Resolution: Workaround

> fix NPE listing wildcard directory on Windows
> -
>
> Key: YARN-5381
> URL: https://issues.apache.org/jira/browse/YARN-5381
> Project: Hadoop YARN
>  Issue Type: Bug
>Reporter: Haibo Chen
>Priority: Blocker
>
> NPE can be thrown when wildcard is used in libjar option and if the cluster 
> is secure. The root cause is that NM can be running as a user that does not 
> have access to resource files that are downloaded by remote users. YARN-5373 
> only fixes the issue on Linux. This jira implements the fix for Windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5409) container-executor always logs to stdout

[Daniel Templeton (JIRA)]

Daniel Templeton created YARN-5409:
--

 Summary: container-executor always logs to stdout
 Key: YARN-5409
 URL: https://issues.apache.org/jira/browse/YARN-5409
 Project: Hadoop YARN
  Issue Type: Bug
  Components: nodemanager
Affects Versions: 2.9.0
Reporter: Daniel Templeton


The container-executor code is written with the intention of having the 
{{LOGFILE}} point to a configurable a stream, but it doesn't appear to ever 
happen.  It's initialized to null in container-executor.c:56 and then set to 
stdout in main.c:71.  In the cases where the output of the container-executor 
is interpreted (e.g. YARN-5373), it would be nice to be able to point the logs 
somewhere other than stdout.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5408) In-memory based implementation of the FederationPolicyStore

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5408:


 Summary: In-memory based implementation of the 
FederationPolicyStore
 Key: YARN-5408
 URL: https://issues.apache.org/jira/browse/YARN-5408
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan
Assignee: Ellen Hui


YARN-3664 defines the FederationPolicyStore API. This JIRA tracks an in-memory 
based implementation which is useful for both single-box testing and for future 
unit tests that depend on the state store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5407) In-memory based implementation of the FederationMembershipStateStore

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5407:


 Summary: In-memory based implementation of the 
FederationMembershipStateStore
 Key: YARN-5407
 URL: https://issues.apache.org/jira/browse/YARN-5407
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan
Assignee: Ellen Hui


YARN-5307 defines the FederationApplicationStateStore API. This JIRA tracks an 
in-memory based implementation which is useful for both single-box testing and 
for future unit tests that depend on the state store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5406) In-memory based implementation of the FederationMembershipStateStore

[Subru Krishnan (JIRA)]

Subru Krishnan created YARN-5406:


 Summary: In-memory based implementation of the 
FederationMembershipStateStore
 Key: YARN-5406
 URL: https://issues.apache.org/jira/browse/YARN-5406
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Subru Krishnan
Assignee: Ellen Hui


YARN-3662 defines the FederationMembershipStateStore API. This JIRA tracks an 
in-memory based implementation which is useful for both single-box testing and 
for future unit tests that depend on the state store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Re: [DISCUSS] YARN-5079 : Native YARN framework layer for services and Apache Slider

[Vinod Kumar Vavilapalli]

Thanks for the discussion and the feedback, everyone!

I sense a general consensus, so am going to go ahead with the branch proposal.

Please regard this as the conclusion of the discussion here. If you have more 
inputs, feel free to jump on to the JIRA YARN-5079!

Thanks again,
+Vinod

> On Jul 14, 2016, at 7:36 PM, Vinod Kumar Vavilapalli  
> wrote:
> 
> Hi, Hadoop YARN community!
> 
> (Cross-posting across Hadoop and Slider communities)
> 
> I opened a JIRA a little while ago to pursue a native YARN framework for 
> services: https://issues.apache.org/jira/browse/YARN-5079.
> 
> It is part of a bigger effort that a bunch of us YARN community members are 
> interested in making progress on: YARN-4692 - [Umbrella] Simplified and 
> first-class support for services in YARN.
> 
> The idea is that with our current attention on making services first­-class, 
> it's time to take a fresh look at how we can make Apache Hadoop YARN support 
> services well out of the box. I’ve been looking at various possibilities - 
> ranging from a custom new framework room scratch to using one of the existing 
> projects - and stopped at Apache Slider (http://slider.incubator.apache.org) 
> given its association with some of the YARN community members (Steve 
> Loughran, Devaraj Das, Arun C Murthy, myself etc.).
> 
> Slider client & AM already handles a great deal of the functionality that we 
> need. I posit that assimilating the client, ApplicationMaster etc of an 
> existing framework like Apache Slider can serve our purpose really well. My 
> early informal discussions about this with few Hadoop and Slider community 
> members yielded generally favourable feedback.
> 
> The Apache Slider incubator community also discussed this and expressed 
> generally positive interest in YARN taking up Slider’s key pieces, you can 
> see that discussion here: https://s.apache.org/0hoh.
> 
> So in summary, we are looking to the following
> 
> - Code
>   — ‘Graduate' key pieces (Slider client, AM) of Apache Slider into Apache 
> Hadoop for providing a native services experiences in YARN
>   — Leave for now some of the pieces behind in Apache Slider - (a) Slider 
> agent as we won’t need it, (b) Slider packages that need more deliberation in 
> terms of where they will live in the long term.
>   — Create a branch in YARN, copy this code over into a new module(s), and 
> work towards completing a functioning app running on YARN.
> 
> - Communities & releases
>   — Good thing is that many of Apache Slider community members are already 
> seasoned folk in the Apache Hadoop ecosystem projects. For those committers & 
> PMC in Slider that are not yet Hadoop committers / PMC, without complicating 
> things much, a proposed path forward is active participation in the branch 
> (as branch committers?) and eventually in mainline YARN and thus go through a 
> natural progression to committership / PMC. Given that most of the members 
> are stalwarts in the Apache communities, this should be a cinch IMO.
>   — The work on this new code can start, and depending on its state, and 
> assuming that the experiment succeeds, can be merged into trunk and later 
> picked up in the next nearest & feasible Apache Hadoop release.
>   — While the work on forked-over-code goes on till we have a functioning 
> app, the current Apache Slider project continues to live, with supporting 
> releases etc. At some point in the future, when things become clearer, more 
> decisions can be taken on the (parts left behind in the) incubating project’s 
> future.
> 
> Thoughts?
> 
> Thanks
> +Vinod


-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Re: [DISCUSS] YARN-5079 : Native YARN framework layer for services and Apache Slider

[Vinod Kumar Vavilapalli]

An interesting proposal, we can continue this discussion on the Slider dev 
lists.

Thanks
+Vinod

> On Jul 19, 2016, at 4:51 PM, jonma...@gmail.com wrote:
> 
> +1 - this approach definitely addresses an important need.
> 
> The project has gone through at least a couple of development/repo
> approaches:
> 
> 1)  git-flow with master/develop branches
> 2)  abandonment of the master branch and work/releases based on the develop
> branch.
> 
> I have no strong objections to the approach above, but given the existence
> of the two branches above, and some developer familiarity with the
> 'develop' branch, perhaps we could:
> 
> 1)  Synch the master branch to the develop branch (not sure which git
> mechanism would best achieve this)
> 2)  Leverage the develop branch to create the agent/app-package based
> Slider distribution
> 
> In this way there'a a legacy branch available while develop continues to
> proceed on the existing and familiar development branch.
> 
> Just a thought.  Like I said - no real strong feelings :)
> 
> On Mon, Jul 18, 2016 at 3:23 PM, Gour Saha  wrote:
> 
>> +1 forwarding from the discussion in Slider DL
>> 
>> Note: On the Slider side, we plan to create a branch corresponding to this
>> YARN branch. In this, we intend to remove all the pieces which will move
>> to the YARN branch (Slider core, AM, client). We will retain the Agent and
>> app-packages which will then depend on the new hadoop-slider module (in
>> addition to the existing hadoop modules that it already depends on). This
>> will create a single view of Slider codebase, exactly as it stands today,
>> fully supporting the current app-packages. Slider can even release its
>> future versions from this new branch, once the hadoop-sldier module
>> reaches a matured state. It will be an easier path for existing Slider
>> users/app-owners to move to the future stable state of Slider completely
>> off of Hadoop YARN codebase. All that would be expected is to migrate the
>> app-packages to the agent-less version. Of course the Slider community
>> will do the migration for the current app-packages in the Slider codebase.
>> 
>> -Gour
>> 
>> On 7/14/16, 7:36 PM, "Vinod Kumar Vavilapalli"  wrote:
>> 
>>> Hi, Hadoop YARN community!
>>> 
>>> (Cross-posting across Hadoop and Slider communities)
>>> 
>>> I opened a JIRA a little while ago to pursue a native YARN framework for
>>> services: https://issues.apache.org/jira/browse/YARN-5079.
>>> 
>>> It is part of a bigger effort that a bunch of us YARN community members
>>> are interested in making progress on: YARN-4692 - [Umbrella] Simplified
>>> and first-class support for services in YARN.
>>> 
>>> The idea is that with our current attention on making services
>>> first­-class, it's time to take a fresh look at how we can make Apache
>>> Hadoop YARN support services well out of the box. I’ve been looking at
>>> various possibilities - ranging from a custom new framework room scratch
>>> to using one of the existing projects - and stopped at Apache Slider
>>> (http://slider.incubator.apache.org) given its association with some of
>>> the YARN community members (Steve Loughran, Devaraj Das, Arun C Murthy,
>>> myself etc.).
>>> 
>>> Slider client & AM already handles a great deal of the functionality that
>>> we need. I posit that assimilating the client, ApplicationMaster etc of
>>> an existing framework like Apache Slider can serve our purpose really
>>> well. My early informal discussions about this with few Hadoop and Slider
>>> community members yielded generally favourable feedback.
>>> 
>>> The Apache Slider incubator community also discussed this and expressed
>>> generally positive interest in YARN taking up Slider’s key pieces, you
>>> can see that discussion here: https://s.apache.org/0hoh.
>>> 
>>> So in summary, we are looking to the following
>>> 
>>> - Code
>>>  ― ‘Graduate' key pieces (Slider client, AM) of Apache Slider into
>>> Apache Hadoop for providing a native services experiences in YARN
>>>  ― Leave for now some of the pieces behind in Apache Slider - (a)
>>> Slider agent as we won’t need it, (b) Slider packages that need more
>>> deliberation in terms of where they will live in the long term.
>>>  ― Create a branch in YARN, copy this code over into a new module(s),
>>> and work towards completing a functioning app running on YARN.
>>> 
>>> - Communities & releases
>>>  ― Good thing is that many of Apache Slider community members are
>>> already seasoned folk in the Apache Hadoop ecosystem projects. For those
>>> committers & PMC in Slider that are not yet Hadoop committers / PMC,
>>> without complicating things much, a proposed path forward is active
>>> participation in the branch (as branch committers?) and eventually in
>>> mainline YARN and thus go through a natural progression to committership
>>> / PMC. Given that most of the members are stalwarts in the Apache
>>> communities, this should be a cinch IMO.
>>>  ― The 

Re: [DISCUSS] YARN-5079 : Native YARN framework layer for services and Apache Slider

[Vinod Kumar Vavilapalli]

If you see comments from Gour (of Apache Slider), that seems like the general 
direction: "All that would be expected is to migrate the app-packages to the 
agent-less version. Of course the Slider community will do the migration for 
the current app-packages in the Slider codebase.”

Whether this means taking an existing package and run it as is on the newer 
framework remains to be seen. One possible solution is to just support today’s 
Slider framework on newer YARN. That way if you have an existing app-package, 
it continues to run on the newer cluster, but for getting some of the newer 
functionality, you may have to move to the newer package.

My personal take is that it will take a bit of effort to make all of this 
happen, but is a very important goal to support existing users and their 
applications.

Thanks
+Vinod

> On Jul 19, 2016, at 3:29 PM, Siddharth Seth  wrote:
> 
> In terms of compatibility and Slider fixes - is the intent to allow
> existing slider packages to work without migrating over to the new
> agent-less, etc implementation in Hadoop. e.g. Assuming the slider
> integration work is released in Hadoop 2.xx - would an existing slider
> package which works on Hadoop-2.6 + Slider 0.91.0 continue to work without
> changes?

Re: [DISCUSS] YARN-5079 : Native YARN framework layer for services and Apache Slider

[Vinod Kumar Vavilapalli]

Yes, that’s the general goal for YARN-4692 also!

Thanks
+Vinod

> On Jul 18, 2016, at 8:14 PM, Arun Suresh  wrote:
> 
> I would also like to see this effort encompass not just services but also
> general long-lived applications

Re: [DISCUSS] YARN-5079 : Native YARN framework layer for services and Apache Slider

[Vinod Kumar Vavilapalli]

This sounds like a good plan for ongoing existence of the code in both the 
places, Gour!

Thanks
+Vinod

> On Jul 18, 2016, at 12:23 PM, Gour Saha  > wrote:
> 
> Note: On the Slider side, we plan to create a branch corresponding to this
> YARN branch. In this, we intend to remove all the pieces which will move
> to the YARN branch (Slider core, AM, client). We will retain the Agent and
> app-packages which will then depend on the new hadoop-slider module (in
> addition to the existing hadoop modules that it already depends on). This
> will create a single view of Slider codebase, exactly as it stands today,
> fully supporting the current app-packages. Slider can even release its
> future versions from this new branch, once the hadoop-sldier module
> reaches a matured state. It will be an easier path for existing Slider
> users/app-owners to move to the future stable state of Slider completely
> off of Hadoop YARN codebase. All that would be expected is to migrate the
> app-packages to the agent-less version. Of course the Slider community
> will do the migration for the current app-packages in the Slider codebase.

Re: Apache MSDN Offer is Back

[Chris Nauroth]

That definitely was possible under the old deal.  You could go through the MSDN 
site and download an iso for various versions of Windows and run it under 
VirtualBox.  The MSDN site also would furnish a license key that you could use 
to activate the machine.

I haven't yet gone through this new process to see if anything has changed in 
the benefits.

--Chris Nauroth

From: Ravi Prakash >
Date: Wednesday, July 20, 2016 at 12:04 PM
To: Chris Nauroth >
Cc: "common-...@hadoop.apache.org" 
>, 
"hdfs-...@hadoop.apache.org" 
>, 
"yarn-dev@hadoop.apache.org" 
>, 
"mapreduce-...@hadoop.apache.org" 
>
Subject: Re: Apache MSDN Offer is Back

Thanks Chris!

I did avail of the offer a few months ago, and wasn't able to figure out if a 
windows license was also available. I want to run windows inside a virtual 
machine on my Linux laptop, for the rare cases that there are patches that may 
affect that. Any clue if that is possible?

Thanks
Ravi

On Tue, Jul 19, 2016 at 4:09 PM, Chris Nauroth 
> wrote:
A few months ago, we learned that the offer for ASF committers to get an MSDN 
license had gone away.  I'm happy to report that as of a few weeks ago, that 
offer is back in place.  For more details, committers can check out 
https://svn.apache.org/repos/private/committers and read 
donated-licenses/msdn.txt.

--Chris Nauroth

Re: Apache MSDN Offer is Back

[Ravi Prakash]

Thanks Chris!

I did avail of the offer a few months ago, and wasn't able to figure out if
a windows license was also available. I want to run windows inside a
virtual machine on my Linux laptop, for the rare cases that there are
patches that may affect that. Any clue if that is possible?

Thanks
Ravi

On Tue, Jul 19, 2016 at 4:09 PM, Chris Nauroth 
wrote:

> A few months ago, we learned that the offer for ASF committers to get an
> MSDN license had gone away.  I'm happy to report that as of a few weeks
> ago, that offer is back in place.  For more details, committers can check
> out https://svn.apache.org/repos/private/committers and read
> donated-licenses/msdn.txt.
>
> --Chris Nauroth
>

[jira] [Created] (YARN-5405) Running yarn application should fail fast if RM get Kerberized after RM restart

[Yesha Vora (JIRA)]

Yesha Vora created YARN-5405:


 Summary: Running yarn application should fail fast if RM get 
Kerberized after RM restart
 Key: YARN-5405
 URL: https://issues.apache.org/jira/browse/YARN-5405
 Project: Hadoop YARN
  Issue Type: Bug
  Components: yarn
Reporter: Yesha Vora


Scenario:

* Start YARN in unsecure mode. (Make sure RM and NM recovery is enabled)
* Start yarn application 
* Enable YARN in secure mode and restart RM

The yarn application is expected to fail fast. Instead, RM tries to recover 
this application and gets Null pointer exception. It also marks application as 
succeeded instead failed. 

{code}
2016-07-15 06:47:09,804 WARN  ipc.Server (Server.java:logException(2399)) - IPC 
Server handler 2 on 8030, call 
org.apache.hadoop.yarn.api.ApplicationMasterProtocolPB.registerApplicationMaster
 from xx.xx.xx.xx:56888 Call#944 Retry#0
java.lang.NullPointerException
at 
org.apache.hadoop.yarn.server.resourcemanager.ApplicationMasterService.registerApplicationMaster(ApplicationMasterService.java:300)
at 
org.apache.hadoop.yarn.api.impl.pb.service.ApplicationMasterProtocolPBServiceImpl.registerApplicationMaster(ApplicationMasterProtocolPBServiceImpl.java:90)
at 
org.apache.hadoop.yarn.proto.ApplicationMasterProtocol$ApplicationMasterProtocolService$2.callBlockingMethod(ApplicationMasterProtocol.java:95)
at 
org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:640)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2313)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2309)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at 
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2307)
2016-07-15 06:47:09,813 INFO  resourcemanager.ApplicationMasterService {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

[Apache Jenkins Server]

For more details, see 
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/100/

[Jul 19, 2016 10:33:28 AM] (varunsaxena) YARN-4996. Make 
TestNMReconnect.testCompareRMNodeAfterReconnect()
[Jul 19, 2016 2:17:58 PM] (junping_du) YARN-5213. Fix a bug in LogCLIHelpers 
which cause
[Jul 19, 2016 5:43:19 PM] (Arun Suresh) Revert "YARN=5181. ClusterNodeTracker: 
add method to get list of nodes
[Jul 19, 2016 5:43:37 PM] (Arun Suresh) YARN-5181. ClusterNodeTracker: add 
method to get list of nodes matching
[Jul 19, 2016 8:49:24 PM] (aajisaka) HDFS-10603. Fix flaky tests in
[Jul 19, 2016 9:46:07 PM] (aajisaka) HDFS-10647. Add a link to HDFS disk 
balancer document in site.xml.
[Jul 19, 2016 10:13:01 PM] (aajisaka) HDFS-10620. StringBuilder created and 
appended even if logging is
[Jul 19, 2016 11:05:48 PM] (aajisaka) HADOOP-12991. Conflicting default ports 
in DelegateToFileSystem.
[Jul 20, 2016 3:15:37 AM] (sjlee) MAPREDUCE-6365. Refactor 
JobResourceUploader#uploadFilesInternal (Chris
[Jul 20, 2016 6:03:58 AM] (Arun Suresh) YARN-5350. Distributed Scheduling: 
Ensure sort order of allocatable




-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org