date:20130607

[jira] [Updated] (YARN-457) Setting updated nodes from null to null causes NPE in AllocateResponsePBImpl

2013-06-07 Thread Kenji Kikushima (JIRA)


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

Kenji Kikushima updated YARN-457:
-

Attachment: YARN-457-5.patch

Added test for setUpdatedNodes setting null.

 Setting updated nodes from null to null causes NPE in AllocateResponsePBImpl
 

 Key: YARN-457
 URL: https://issues.apache.org/jira/browse/YARN-457
 Project: Hadoop YARN
  Issue Type: Bug
  Components: api
Affects Versions: 2.0.3-alpha
Reporter: Sandy Ryza
Assignee: Kenji Kikushima
Priority: Minor
  Labels: Newbie
 Attachments: YARN-457-2.patch, YARN-457-3.patch, YARN-457-4.patch, 
 YARN-457-5.patch, YARN-457.patch


 {code}
 if (updatedNodes == null) {
   this.updatedNodes.clear();
   return;
 }
 {code}
 If updatedNodes is already null, a NullPointerException is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-721) ContainerManagerImpl failed to authorizeRequest

2013-06-07 Thread PengZhang (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677852#comment-13677852
 ] 

PengZhang commented on YARN-721:


I checked YARN-370 and YARN-382，I think it's the same problem with this issue.
I'm using cdh4.2 and found that SchedulerUtils.java in trunk not changed, so I 
mistakenly assumed that the bug was not fixed.

And I agreed that YARN-382 is a better fix. 

 ContainerManagerImpl failed to authorizeRequest
 ---

 Key: YARN-721
 URL: https://issues.apache.org/jira/browse/YARN-721
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.0.3-alpha
Reporter: PengZhang
 Attachments: YARN-721.patch


 When security is enabled, resource check will be failed. AM master cannot be 
 launched.
 It reports like Expected resource memory:1800, vCores:1 but found 
 memory:1536, vCores:1
 I tracked this problem, and found it's imported in YARN-2. In 
 RMAppAttemptImpl.ScheduleTransition, after allocate(), scheduler normalized 
 Resource and created a new Resource object. Resource objects in scheduler and 
 RMAppAttemptImp are used for schedule and launch separately. The difference 
 value met in ContainerManagerImpl, and caused this problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (YARN-553) Have GetNewApplicationResponse generate a directly usable ApplicationSubmissionContext

2013-06-07 Thread Karthik Kambatla (JIRA)


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

Karthik Kambatla updated YARN-553:
--

Attachment: yarn-553-2.patch

Fix the javadoc warning.

 Have GetNewApplicationResponse generate a directly usable 
 ApplicationSubmissionContext
 --

 Key: YARN-553
 URL: https://issues.apache.org/jira/browse/YARN-553
 Project: Hadoop YARN
  Issue Type: Sub-task
  Components: client
Affects Versions: 2.0.3-alpha
Reporter: Harsh J
Assignee: Karthik Kambatla
Priority: Minor
 Attachments: yarn-553-1.patch, yarn-553-2.patch


 Right now, we're doing multiple steps to create a relevant 
 ApplicationSubmissionContext for a pre-received GetNewApplicationResponse.
 {code}
 GetNewApplicationResponse newApp = yarnClient.getNewApplication();
 ApplicationId appId = newApp.getApplicationId();
 ApplicationSubmissionContext appContext = 
 Records.newRecord(ApplicationSubmissionContext.class);
 appContext.setApplicationId(appId);
 {code}
 A simplified way may be to have the GetNewApplicationResponse itself provide 
 a helper method that builds a usable ApplicationSubmissionContext for us. 
 Something like:
 {code}
 GetNewApplicationResponse newApp = yarnClient.getNewApplication();
 ApplicationSubmissionContext appContext = 
 newApp.generateApplicationSubmissionContext();
 {code}
 [The above method can also take an arg for the container launch spec, or 
 perhaps pre-load defaults like min-resource, etc. in the returned object, 
 aside of just associating the application ID automatically.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-773) Move YarnRuntimeException from package api.yarn to api.yarn.exceptions

2013-06-07 Thread Steve Loughran (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677906#comment-13677906
 ] 

Steve Loughran commented on YARN-773:
-

# Given the grief I had with the last exception rebasing, I'd clearly like to 
get my -117 patch in first.
# That failing test is one that I'd already patched there, as it was too 
brittle against exception time and location of the test; as wrapping of 
exceptions changed it would break. The patched version looks for the string on 
a contains, not an equals

{code}
  if(!e.getMessage().contains(errMessage)) {
throw e;
  }
{code}

Even those tests are brittle against the error text changing -the text should 
be moved to constant strings in the source files and referenced by the tests


 Move YarnRuntimeException from package api.yarn to api.yarn.exceptions
 --

 Key: YARN-773
 URL: https://issues.apache.org/jira/browse/YARN-773
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Jian He
Assignee: Jian He
 Attachments: YARN-773.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-773) Move YarnRuntimeException from package api.yarn to api.yarn.exceptions

2013-06-07 Thread Steve Loughran (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677908#comment-13677908
 ] 

Steve Loughran commented on YARN-773:
-

I like new exception classes for testability. If an existing class is to be 
used, the error string has to be made a constant, with the test referencing it 
directly, rather than having a cut-and-paste copy of the string

 Move YarnRuntimeException from package api.yarn to api.yarn.exceptions
 --

 Key: YARN-773
 URL: https://issues.apache.org/jira/browse/YARN-773
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Jian He
Assignee: Jian He
 Attachments: YARN-773.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-773) Move YarnRuntimeException from package api.yarn to api.yarn.exceptions

2013-06-07 Thread Steve Loughran (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677917#comment-13677917
 ] 

Steve Loughran commented on YARN-773:
-

(ignore last comment, wrong JIRA)

 Move YarnRuntimeException from package api.yarn to api.yarn.exceptions
 --

 Key: YARN-773
 URL: https://issues.apache.org/jira/browse/YARN-773
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Jian He
Assignee: Jian He
 Attachments: YARN-773.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-689) Add multiplier unit to resourcecapabilities

2013-06-07 Thread Tom White (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677937#comment-13677937
 ] 

Tom White commented on YARN-689:


+1 to Hitesh and Bikas' points about minimum (and increment) being an internal 
scheduling artifact, and removing it from the API (or at least making it clear 
that AMs shouldn't use it as a multiplier).

 Add multiplier unit to resourcecapabilities
 ---

 Key: YARN-689
 URL: https://issues.apache.org/jira/browse/YARN-689
 Project: Hadoop YARN
  Issue Type: Sub-task
  Components: api, scheduler
Affects Versions: 2.0.4-alpha
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
 Attachments: YARN-689.patch, YARN-689.patch, YARN-689.patch, 
 YARN-689.patch, YARN-689.patch


 Currently we overloading the minimum resource value as the actual multiplier 
 used by the scheduler.
 Today with a minimum memory set to 1GB, requests for 1.5GB are always 
 translated to allocation of 2GB.
 We should decouple the minimum allocation from the multiplier.
 The multiplier should also be exposed to the client via the 
 RegisterApplicationMasterResponse

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (YARN-404) Node Manager leaks Data Node connections

2013-06-07 Thread Devaraj K (JIRA)


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

Devaraj K resolved YARN-404.


Resolution: Duplicate

 Node Manager leaks Data Node connections
 

 Key: YARN-404
 URL: https://issues.apache.org/jira/browse/YARN-404
 Project: Hadoop YARN
  Issue Type: Bug
  Components: nodemanager, resourcemanager
Affects Versions: 2.0.2-alpha, 0.23.6
Reporter: Devaraj K
Assignee: Devaraj K

 RM is missing to give some applications to NM for clean up, due to this log 
 aggregation is not happening for those applications and also it is leaking 
 data node connections in NM side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (YARN-298) ResourceManager Cluster Applications REST API throws NPE

2013-06-07 Thread Devaraj K (JIRA)


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

Devaraj K updated YARN-298:
---

Affects Version/s: 2.0.1-alpha

 ResourceManager Cluster Applications REST API throws NPE
 

 Key: YARN-298
 URL: https://issues.apache.org/jira/browse/YARN-298
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.0.1-alpha
Reporter: Devaraj K

 {code:xml}
 2012-12-28 06:03:49,125 WARN 
 org.apache.hadoop.yarn.webapp.GenericExceptionHandler: INTERNAL_SERVER_ERROR
 java.lang.NullPointerException
   at 
 org.apache.hadoop.yarn.server.security.ApplicationACLsManager.checkAccess(ApplicationACLsManager.java:104)
   at 
 org.apache.hadoop.yarn.server.resourcemanager.webapp.RMWebServices.hasAccess(RMWebServices.java:100)
   at 
 org.apache.hadoop.yarn.server.resourcemanager.webapp.RMWebServices.getApps(RMWebServices.java:362)
   at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
   at 
 com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
   at 
 com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
   at 
 com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
   at 
 com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
   at 
 com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
   at 
 com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
   at 
 com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
   at 
 com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
   at 
 com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
   at 
 com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
   at 
 com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
   at 
 com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
   at 
 com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
   at 
 com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:886)
   at 
 com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:834)
   at 
 com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:795)
   at 
 com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
   at 
 com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
   at 
 com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
   at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.apache.hadoop.util.IpValidationFilter.doFilter(IpValidationFilter.java:60)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:985)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at

[jira] [Resolved] (YARN-781) Expose LOGDIR that containers should use for logging

2013-06-07 Thread Arun C Murthy (JIRA)


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

Arun C Murthy resolved YARN-781.


Resolution: Duplicate

Duplicate of YARN-772.

 Expose LOGDIR that containers should use for logging
 

 Key: YARN-781
 URL: https://issues.apache.org/jira/browse/YARN-781
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Devaraj Das
Assignee: Vinod Kumar Vavilapalli

 The LOGDIR is known. We should expose this to the container's environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-767) Initialize Application status metrics when QueueMetrics is initialized

2013-06-07 Thread Arun C Murthy (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678013#comment-13678013
 ] 

Arun C Murthy commented on YARN-767:


The patch looks good.

Nit: initAppStatusMetrics should be a private method.

 Initialize Application status metrics  when QueueMetrics is initialized
 ---

 Key: YARN-767
 URL: https://issues.apache.org/jira/browse/YARN-767
 Project: Hadoop YARN
  Issue Type: Bug
Reporter: Jian He
Assignee: Jian He
 Attachments: YARN-767.1.patch


 Applications: ResourceManager.QueueMetrics.AppsSubmitted, 
 ResourceManager.QueueMetrics.AppsRunning, 
 ResourceManager.QueueMetrics.AppsPending, 
 ResourceManager.QueueMetrics.AppsCompleted, 
 ResourceManager.QueueMetrics.AppsKilled, 
 ResourceManager.QueueMetrics.AppsFailed
 For now these metrics are created only when they are needed, we want to make 
 them be seen when QueueMetrics is initialized

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-648) FS: Add documentation for pluggable policy

2013-06-07 Thread Karthik Kambatla (JIRA)

[
https://issues.apache.org/jira/browse/YARN-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678096#comment-13678096
]

Karthik Kambatla commented on YARN-648:
---

bq. What do you mean by latency? A policy that is compute-intensive can still
slow down things for everyone.

Agree, I should probably leave out the latency and just leave it as configure
appropriate policy.

However, I believe latency is also one of the reasons. Consider a configuration
where root.a and root.b are to parent queues, configured to use fairshare and
SP (a sophisticated scheduler with higher latency than fairshare) respectively.
root itself has fairshare. Now, the apps under root.a don't suffer from the
overhead of SP. Further, in the future, scheduling within a queue can be done
asynchronously to achieve even higher throughput and the time to schedule an
app depends on the cumulative latencies of parent queue schedulers? If I
understand it right, Omega (Google) was built to handle such latencies in the
presence of sophisticated schedulers.

FS: Add documentation for pluggable policy
--

Key: YARN-648
URL: https://issues.apache.org/jira/browse/YARN-648
Project: Hadoop YARN
Issue Type: Bug
Components: scheduler
Affects Versions: 2.0.4-alpha
Reporter: Karthik Kambatla
Assignee: Karthik Kambatla
Labels: documentaion
Attachments: yarn-648-1.patch

YARN-469 and YARN-482 make the scheduling policy in FS pluggable. Need to add
documentation on how to use this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-760) NodeManager throws AvroRuntimeException on failed start

2013-06-07 Thread Junping Du (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678109#comment-13678109
 ] 

Junping Du commented on YARN-760:
-

Patch looks good to me. Someone can help to review and commit it? Thanks!

 NodeManager throws AvroRuntimeException on failed start
 ---

 Key: YARN-760
 URL: https://issues.apache.org/jira/browse/YARN-760
 Project: Hadoop YARN
  Issue Type: Bug
  Components: nodemanager
Affects Versions: 2.0.4-alpha
Reporter: Sandy Ryza
Assignee: Niranjan Singh
  Labels: newbie
 Attachments: YARN-760.patch, YARN-760.patch, YARN-760.patch


 NodeManager wraps exceptions that occur in its start method in 
 AvroRuntimeExceptions, even though it doesn't use Avro anywhere else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (YARN-783) RM and NM web server /logs pages link not working

2013-06-07 Thread Binglin Chang (JIRA)

Binglin Chang created YARN-783:
--

 Summary: RM and NM web server /logs pages link not working
 Key: YARN-783
 URL: https://issues.apache.org/jira/browse/YARN-783
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.1.0-beta
Reporter: Binglin Chang


RM and NM web server /logs page link to main default apps page

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (YARN-784) YARN does not provide Version info in JMX like hdfs and mapreducev1

2013-06-07 Thread Binglin Chang (JIRA)

Binglin Chang created YARN-784:
--

 Summary: YARN does not provide Version info in JMX like hdfs and 
mapreducev1
 Key: YARN-784
 URL: https://issues.apache.org/jira/browse/YARN-784
 Project: Hadoop YARN
  Issue Type: Improvement
Reporter: Binglin Chang
Priority: Minor


Some third party tool may still need this version info in JMX. Better add this 
for backward compatibility.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-760) NodeManager throws AvroRuntimeException on failed start

2013-06-07 Thread Jason Lowe (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678110#comment-13678110
 ] 

Jason Lowe commented on YARN-760:
-

+1, will commit shortly

 NodeManager throws AvroRuntimeException on failed start
 ---

 Key: YARN-760
 URL: https://issues.apache.org/jira/browse/YARN-760
 Project: Hadoop YARN
  Issue Type: Bug
  Components: nodemanager
Affects Versions: 2.0.4-alpha
Reporter: Sandy Ryza
Assignee: Niranjan Singh
  Labels: newbie
 Attachments: YARN-760.patch, YARN-760.patch, YARN-760.patch


 NodeManager wraps exceptions that occur in its start method in 
 AvroRuntimeExceptions, even though it doesn't use Avro anywhere else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (YARN-784) YARN does not provide Version info in JMX like hdfs and mapreducev1

2013-06-07 Thread Binglin Chang (JIRA)


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

Binglin Chang updated YARN-784:
---

Affects Version/s: 2.1.0-beta

 YARN does not provide Version info in JMX like hdfs and mapreducev1
 ---

 Key: YARN-784
 URL: https://issues.apache.org/jira/browse/YARN-784
 Project: Hadoop YARN
  Issue Type: Improvement
Affects Versions: 2.1.0-beta
Reporter: Binglin Chang
Priority: Minor

 Some third party tool may still need this version info in JMX. Better add 
 this for backward compatibility.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-783) RM and NM web server /logs pages link not working

2013-06-07 Thread Binglin Chang (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678112#comment-13678112
 ] 

Binglin Chang commented on YARN-783:


The problem seems to only exist in extra jetty context root, like /logs/ and 
/static/, and none root paths work fine, like /logs/userlogs/

 RM and NM web server /logs pages link not working
 -

 Key: YARN-783
 URL: https://issues.apache.org/jira/browse/YARN-783
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.1.0-beta
Reporter: Binglin Chang

 RM and NM web server /logs page link to main default apps page

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-760) NodeManager throws AvroRuntimeException on failed start

2013-06-07 Thread Niranjan Singh (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678127#comment-13678127
 ] 

Niranjan Singh commented on YARN-760:
-

Thanks to Jason Lowe, Junping Du and Sandy Ryza for all your help.

 NodeManager throws AvroRuntimeException on failed start
 ---

 Key: YARN-760
 URL: https://issues.apache.org/jira/browse/YARN-760
 Project: Hadoop YARN
  Issue Type: Bug
  Components: nodemanager
Affects Versions: 2.0.4-alpha
Reporter: Sandy Ryza
Assignee: Niranjan Singh
  Labels: newbie
 Fix For: 2.1.0-beta

 Attachments: YARN-760.patch, YARN-760.patch, YARN-760.patch


 NodeManager wraps exceptions that occur in its start method in 
 AvroRuntimeExceptions, even though it doesn't use Avro anywhere else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (YARN-781) Expose LOGDIR that containers should use for logging

2013-06-07 Thread Vinod Kumar Vavilapalli (JIRA)


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

Vinod Kumar Vavilapalli reopened YARN-781:
--


I read this as more than just documentation. It is about exposing the final 
LOGDIR as env to the containers so that they can decide where to write logs at 
run-time.

As of today, AMs do have a not-so-straight way of doing this: an AM can 
explicitly set SOMEENV=LOGDIR and we promptly do the appropriate string 
replacement. But I think it is useful to set it explicitly.

 Expose LOGDIR that containers should use for logging
 

 Key: YARN-781
 URL: https://issues.apache.org/jira/browse/YARN-781
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Devaraj Das
Assignee: Vinod Kumar Vavilapalli

 The LOGDIR is known. We should expose this to the container's environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-642) Fix up /nodes REST API to have 1 param and be consistent with the Java API

2013-06-07 Thread Vinod Kumar Vavilapalli (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678176#comment-13678176
 ] 

Vinod Kumar Vavilapalli commented on YARN-642:
--

Looking at it now..

 Fix up /nodes REST API to have 1 param and be consistent with the Java API
 --

 Key: YARN-642
 URL: https://issues.apache.org/jira/browse/YARN-642
 Project: Hadoop YARN
  Issue Type: Bug
  Components: api, resourcemanager
Affects Versions: 2.0.4-alpha
Reporter: Sandy Ryza
Assignee: Sandy Ryza
  Labels: incompatible
 Attachments: YARN-642-1.patch, YARN-642-2.patch, YARN-642-2.patch, 
 YARN-642.patch


 The code behind the /nodes RM REST API is unnecessarily muddled, logs the 
 same misspelled INFO message repeatedly, and does not return unhealthy nodes, 
 even when asked.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-775) stream jobs are not cleaning the Yarn local-dirs after container is released

2013-06-07 Thread yeshavora (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678174#comment-13678174
 ] 

yeshavora commented on YARN-775:


Setting yarn.nodemanager.delete.debug-delay-sec solves the issue. Closing this 
Jira

 stream jobs are not cleaning the Yarn local-dirs after container is released
 

 Key: YARN-775
 URL: https://issues.apache.org/jira/browse/YARN-775
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.1.0-beta
Reporter: yeshavora
Assignee: Omkar Vinit Joshi
 Fix For: 2.1.0-beta


 Run a stream job:
 hadoop jar hadoop-streaming.jar -files file:///tmp/Tmp.py -input Tmp.py 
 -output /tmp/Tmpout -mapper python Tmp.py -reducer NONE
 Container Dirs are not being cleaned after Stream job is 
 completed/Killed/Failed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (YARN-775) stream jobs are not cleaning the Yarn local-dirs after container is released

2013-06-07 Thread yeshavora (JIRA)


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

yeshavora resolved YARN-775.


Resolution: Invalid

 stream jobs are not cleaning the Yarn local-dirs after container is released
 

 Key: YARN-775
 URL: https://issues.apache.org/jira/browse/YARN-775
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.1.0-beta
Reporter: yeshavora
Assignee: Omkar Vinit Joshi
 Fix For: 2.1.0-beta


 Run a stream job:
 hadoop jar hadoop-streaming.jar -files file:///tmp/Tmp.py -input Tmp.py 
 -output /tmp/Tmpout -mapper python Tmp.py -reducer NONE
 Container Dirs are not being cleaned after Stream job is 
 completed/Killed/Failed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (YARN-767) Initialize Application status metrics when QueueMetrics is initialized

2013-06-07 Thread Jian He (JIRA)


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

Jian He updated YARN-767:
-

Attachment: YARN-767.2.patch

Add a test, and fix the visibility of the method

 Initialize Application status metrics  when QueueMetrics is initialized
 ---

 Key: YARN-767
 URL: https://issues.apache.org/jira/browse/YARN-767
 Project: Hadoop YARN
  Issue Type: Bug
Reporter: Jian He
Assignee: Jian He
 Attachments: YARN-767.1.patch, YARN-767.2.patch


 Applications: ResourceManager.QueueMetrics.AppsSubmitted, 
 ResourceManager.QueueMetrics.AppsRunning, 
 ResourceManager.QueueMetrics.AppsPending, 
 ResourceManager.QueueMetrics.AppsCompleted, 
 ResourceManager.QueueMetrics.AppsKilled, 
 ResourceManager.QueueMetrics.AppsFailed
 For now these metrics are created only when they are needed, we want to make 
 them be seen when QueueMetrics is initialized

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-457) Setting updated nodes from null to null causes NPE in AllocateResponsePBImpl

2013-06-07 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678199#comment-13678199
 ] 

Hadoop QA commented on YARN-457:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12586663/YARN-457-5.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-YARN-Build/1158//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1158//console

This message is automatically generated.

 Setting updated nodes from null to null causes NPE in AllocateResponsePBImpl
 

 Key: YARN-457
 URL: https://issues.apache.org/jira/browse/YARN-457
 Project: Hadoop YARN
  Issue Type: Bug
  Components: api
Affects Versions: 2.0.3-alpha
Reporter: Sandy Ryza
Assignee: Kenji Kikushima
Priority: Minor
  Labels: Newbie
 Attachments: YARN-457-2.patch, YARN-457-3.patch, YARN-457-4.patch, 
 YARN-457-5.patch, YARN-457.patch


 {code}
 if (updatedNodes == null) {
   this.updatedNodes.clear();
   return;
 }
 {code}
 If updatedNodes is already null, a NullPointerException is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-553) Have GetNewApplicationResponse generate a directly usable ApplicationSubmissionContext

2013-06-07 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678201#comment-13678201
 ] 

Hadoop QA commented on YARN-553:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12586672/yarn-553-2.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell
 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-unmanaged-am-launcher
 hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-YARN-Build/1157//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1157//console

This message is automatically generated.

 Have GetNewApplicationResponse generate a directly usable 
 ApplicationSubmissionContext
 --

 Key: YARN-553
 URL: https://issues.apache.org/jira/browse/YARN-553
 Project: Hadoop YARN
  Issue Type: Sub-task
  Components: client
Affects Versions: 2.0.3-alpha
Reporter: Harsh J
Assignee: Karthik Kambatla
Priority: Minor
 Attachments: yarn-553-1.patch, yarn-553-2.patch


 Right now, we're doing multiple steps to create a relevant 
 ApplicationSubmissionContext for a pre-received GetNewApplicationResponse.
 {code}
 GetNewApplicationResponse newApp = yarnClient.getNewApplication();
 ApplicationId appId = newApp.getApplicationId();
 ApplicationSubmissionContext appContext = 
 Records.newRecord(ApplicationSubmissionContext.class);
 appContext.setApplicationId(appId);
 {code}
 A simplified way may be to have the GetNewApplicationResponse itself provide 
 a helper method that builds a usable ApplicationSubmissionContext for us. 
 Something like:
 {code}
 GetNewApplicationResponse newApp = yarnClient.getNewApplication();
 ApplicationSubmissionContext appContext = 
 newApp.generateApplicationSubmissionContext();
 {code}
 [The above method can also take an arg for the container launch spec, or 
 perhaps pre-load defaults like min-resource, etc. in the returned object, 
 aside of just associating the application ID automatically.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-602) NodeManager should mandatorily set some Environment variables into every containers that it launches

2013-06-07 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678204#comment-13678204
 ] 

Hadoop QA commented on YARN-602:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12586012/YARN-602.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-YARN-Build/1156//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1156//console

This message is automatically generated.

 NodeManager should mandatorily set some Environment variables into every 
 containers that it launches
 

 Key: YARN-602
 URL: https://issues.apache.org/jira/browse/YARN-602
 Project: Hadoop YARN
  Issue Type: Bug
Reporter: Xuan Gong
Assignee: Kenji Kikushima
 Attachments: YARN-602.patch


 NodeManager should mandatorily set some Environment variables into every 
 containers that it launches, such as Environment.user, Environment.pwd. If 
 both users and NodeManager set those variables, the value set by NM should be 
 used 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-641) Make AMLauncher in RM Use NMClient

2013-06-07 Thread Siddharth Seth (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678212#comment-13678212
 ] 

Siddharth Seth commented on YARN-641:
-

I don't think yarn-client should have a dependency on the ResourceManager. We 
could move the tests (maybe to a yarn-clien-test module) or re-factor the tests 
to not use the RM at all - may be difficult since some of the tests use the 
MiniYARNCluster. 

 Make AMLauncher in RM Use NMClient
 --

 Key: YARN-641
 URL: https://issues.apache.org/jira/browse/YARN-641
 Project: Hadoop YARN
  Issue Type: Bug
Reporter: Zhijie Shen
Assignee: Zhijie Shen

 YARN-422 adds NMClient. RM's AMLauncher is responsible for the interactions 
 with an application's AM container. AMLauncher should also replace the raw 
 ContainerManager proxy with NMClient.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (YARN-785) Every startContainer request send a set of information (auxiliary service related information) which is redundant. Can be replace with single API.

2013-06-07 Thread Omkar Vinit Joshi (JIRA)

Omkar Vinit Joshi created YARN-785:
--

 Summary: Every startContainer request send a set of information 
(auxiliary service related information) which is redundant. Can be replace with 
single API.
 Key: YARN-785
 URL: https://issues.apache.org/jira/browse/YARN-785
 Project: Hadoop YARN
  Issue Type: Improvement
Reporter: Omkar Vinit Joshi
Assignee: Omkar Vinit Joshi


At present we are sending bunch of information mainly related to auxiliary 
serivces to whoever launches the container. This is an added overhead for NM. 
Instead we can expose this as an API then using NMToken client can get this 
information whenever it needs it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (YARN-785) Every startContainer request send a set of information (auxiliary service related information) which is redundant. Can be replaced with single NodeManager API.

2013-06-07 Thread Omkar Vinit Joshi (JIRA)


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

Omkar Vinit Joshi updated YARN-785:
---

Summary: Every startContainer request send a set of information (auxiliary 
service related information) which is redundant. Can be replaced with single 
NodeManager API.  (was: Every startContainer request send a set of information 
(auxiliary service related information) which is redundant. Can be replace with 
single API.)

 Every startContainer request send a set of information (auxiliary service 
 related information) which is redundant. Can be replaced with single 
 NodeManager API.
 ---

 Key: YARN-785
 URL: https://issues.apache.org/jira/browse/YARN-785
 Project: Hadoop YARN
  Issue Type: Improvement
Reporter: Omkar Vinit Joshi
Assignee: Omkar Vinit Joshi

 At present we are sending bunch of information mainly related to auxiliary 
 serivces to whoever launches the container. This is an added overhead for NM. 
 Instead we can expose this as an API then using NMToken client can get this 
 information whenever it needs it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-702) minicluster classpath construction requires user to set yarn.is.minicluster in the job conf

2013-06-07 Thread Siddharth Seth (JIRA)

[
https://issues.apache.org/jira/browse/YARN-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678221#comment-13678221
]

Siddharth Seth commented on YARN-702:
-

bq. I don't like the idea of the mr client layer needed to know which settings
to extract from the minimrcluster's config from an encapsulation point of view
Do you mean users of the MR client - i.e. HBase, PIG, or anyone trying to
submit a job to the MiniMRCluster? I'd agree, clients pulling individual config
keys is a terrible way to get these clients working.

bq. This sounds great. This would be a method of some sort that we pass in a
Confiugration into that either mutates it?
Either a method to mutate the user specific configuration, or a method to
return a configuration which users can then merge into their configuration
(this already exists, but is a giant set of config parameters). I'm OK with
either approach.

minicluster classpath construction requires user to set yarn.is.minicluster
in the job conf
---

Key: YARN-702
URL: https://issues.apache.org/jira/browse/YARN-702
Project: Hadoop YARN
Issue Type: Improvement
Components: nodemanager
Affects Versions: 2.0.4-alpha
Reporter: Sandy Ryza
Assignee: Sandy Ryza

YARN-129 improved classpath construction for miniclusters by, when
yarn.is.minicluster is set, adding the current JVM's classpath to the
ContainerLaunchContext for the MR AM and tasks. An issue with this is that
it requires the user to set yarn.is.minicluster on the mapreduce side in the
job conf, if they are not copying to RM conf into the jobconf.
I think it would be better to bypass the ContainerLaunchContext and instead
have the nodemanager check the property, and if it is true, do the classpath
additions there.

[jira] [Assigned] (YARN-339) TestResourceTrackerService is failing intermittently

2013-06-07 Thread Jian He (JIRA)


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

Jian He reassigned YARN-339:


Assignee: Jian He

 TestResourceTrackerService is failing intermittently
 

 Key: YARN-339
 URL: https://issues.apache.org/jira/browse/YARN-339
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 3.0.0, 0.23.5
Reporter: Ravi Prakash
Assignee: Jian He

 The test after testReconnectNode() is failing usually. This might be a race 
 condition in Metrics2 code. 
 Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.127 sec  
 FAILURE!
 testDecommissionWithIncludeHosts(org.apache.hadoop.yarn.server.resourcemanager.TestResourceTrackerService)
   Time elapsed: 55 sec   ERROR!
 org.apache.hadoop.metrics2.MetricsException: Metrics source ClusterMetrics 
 already exists!
   at 
 org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.newSourceName(DefaultMetricsSystem.java:134)
   at 
 org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.sourceName(DefaultMetricsSystem.java:115)
   at 
 org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:217)
   at 
 org.apache.hadoop.yarn.server.resourcemanager.ClusterMetrics.registerMetrics(ClusterMetrics.java:71)
   at 
 org.apache.hadoop.yarn.server.resourcemanager.ClusterMetrics.getMetrics(ClusterMetrics.java:58)
   at 
 org.apache.hadoop.yarn.server.resourcemanager.TestResourceTrackerService.testDecommissionWithIncludeHosts(TestResourceTrackerService.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (YARN-752) In AMRMClient, automatically add corresponding rack requests for requested nodes

2013-06-07 Thread Siddharth Seth (JIRA)


[ 
https://issues.apache.org/jira/browse/YARN-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678228#comment-13678228
 ] 

Siddharth Seth commented on YARN-752:
-

Can we make this rack resolution optional
1) If the user has provided racks - just trust that information instead of 
resolving and then checking whether the user has provided the correct 
information.
2) Does it make sense to have an option to disable this automatic resolution. I 
haven't been following the whitelisting / blacklisting closely - but isn't it 
possible for users to ask for specific hosts, without specifying racks 
(Ignoring scheduler implementation here)

 In AMRMClient, automatically add corresponding rack requests for requested 
 nodes
 

 Key: YARN-752
 URL: https://issues.apache.org/jira/browse/YARN-752
 Project: Hadoop YARN
  Issue Type: Improvement
  Components: api, applications
Affects Versions: 2.0.4-alpha
Reporter: Sandy Ryza
Assignee: Sandy Ryza
 Attachments: YARN-752-1.patch, YARN-752-1.patch, YARN-752.patch


 A ContainerRequest that includes node-level requests must also include 
 matching rack-level requests for the racks that those nodes are on.  When a 
 node is present without its rack, it makes sense for the client to 
 automatically add the node's rack.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (YARN-777) Remove unreferenced objects from proto

2013-06-07 Thread Jian He (JIRA)


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

Jian He updated YARN-777:
-

Attachment: YARN-777.patch

After investigation, only found one unused object, 
yarn_protos.proto.StringURLMapProto

 Remove unreferenced objects from proto
 --

 Key: YARN-777
 URL: https://issues.apache.org/jira/browse/YARN-777
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Jian He
Assignee: Jian He
 Attachments: YARN-777.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 >

1 - 100 of 107 matches

Mail list logo