[jira] [Commented] (HADOOP-15514) NoClassDefFoundError of TimelineCollectorManager when starting MiniCluster

2018-06-05 Thread Jeff Zhang (JIRA) 


[ 
https://issues.apache.org/jira/browse/HADOOP-15514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502827#comment-16502827
 ] 

Jeff Zhang commented on HADOOP-15514:
-

This patch works for zeppelin which use hadoop for integration test. Thanks 
[~rohithsharma]

> NoClassDefFoundError of TimelineCollectorManager when starting MiniCluster
> --
>
> Key: HADOOP-15514
> URL: https://issues.apache.org/jira/browse/HADOOP-15514
> Project: Hadoop Common
>  Issue Type: Sub-task
>Affects Versions: 3.0.0
>Reporter: Jeff Zhang
>Assignee: Rohith Sharma K S
>Priority: Major
> Attachments: HADOOP-15514.01.patch
>
>
> {code:java}
> org.apache.hadoop.yarn.exceptions.YarnRuntimeException: 
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/yarn/server/timelineservice/collector/TimelineCollectorManager
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>   at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (HADOOP-15514) NoClassDefFoundError of TimelineCollectorManager when starting MiniCluster

2018-06-04 Thread Jeff Zhang (JIRA) 
Jeff Zhang created HADOOP-15514:
---

 Summary: NoClassDefFoundError of TimelineCollectorManager when 
starting MiniCluster
 Key: HADOOP-15514
 URL: https://issues.apache.org/jira/browse/HADOOP-15514
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Jeff Zhang


{code:java}
org.apache.hadoop.yarn.exceptions.YarnRuntimeException: 
java.lang.NoClassDefFoundError: 
org/apache/hadoop/yarn/server/timelineservice/collector/TimelineCollectorManager

  at java.net.URLClassLoader.findClass(URLClassLoader.java:381)

  at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)

  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

  at java.lang.ClassLoader.defineClass1(Native Method)

  at java.lang.ClassLoader.defineClass(ClassLoader.java:763)

  at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

  at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)

  at java.net.URLClassLoader.access$100(URLClassLoader.java:73)

  at java.net.URLClassLoader$1.run(URLClassLoader.java:368)

  at java.net.URLClassLoader$1.run(URLClassLoader.java:362)

  at java.security.AccessController.doPrivileged(Native Method)

  at java.net.URLClassLoader.findClass(URLClassLoader.java:361)

  at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)

  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

  at java.lang.Class.getDeclaredMethods0(Native Method)

  at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)

  at java.lang.Class.getDeclaredMethods(Class.java:1975){code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (HADOOP-12028) Allow to set handler thread name when building IPC Server

2015-06-17 Thread Jeff Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591094#comment-14591094
 ] 

Jeff Zhang commented on HADOOP-12028:
-

[~gliptak] it lgtm, but you may need +1 from hadoop committer. I am not hadoop 
committer. 

> Allow to set handler thread name when building IPC Server
> -
>
> Key: HADOOP-12028
> URL: https://issues.apache.org/jira/browse/HADOOP-12028
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.7.0
>Reporter: Jeff Zhang
>Priority: Minor
> Attachments: HADOOP-12028.1.patch
>
>
> Currently IPC use the server port to differentiate it with other IPC server. 
> This is not very clear especially when port is randomly generated. It is 
> better to set the server name when building the server and use the server 
> name  as the part of handler thread name 
> {code}
> 2015-05-25 10:43:40,181 INFO  [IPC Server handler 0 on 58849] 
> history.HistoryEventHandler 
> (HistoryEventHandler.java:handleCriticalEvent(110)) - 
> [HISTORY][DAG:dag_1432521818638_0001_1][Event:DAG_SUBMITTED]: 
> dagID=dag_1432521818638_0001_1, submitTime=1432521820100
> 2015-05-25 10:43:40,200 INFO  [IPC Server handler 0 on 58849] impl.DAGImpl 
> (DAGImpl.java:assignDAGScheduler(1360)) - Using DAG Scheduler: 
> org.apache.tez.dag.app.dag.impl.DAGSchedulerNaturalOrderControlled
> 2015-05-25 10:43:40,201 INFO  [IPC Server handler 0 on 58849] h
> {code}



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

[jira] [Commented] (HADOOP-12028) Allow to set handler thread name when building IPC Server

2015-05-25 Thread Jeff Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14558587#comment-14558587
 ] 

Jeff Zhang commented on HADOOP-12028:
-

[~gliptak] That sounds good

> Allow to set handler thread name when building IPC Server
> -
>
> Key: HADOOP-12028
> URL: https://issues.apache.org/jira/browse/HADOOP-12028
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.7.0
>Reporter: Jeff Zhang
>Priority: Minor
> Attachments: HADOOP-12028.1.patch
>
>
> Currently IPC use the server port to differentiate it with other IPC server. 
> This is not very clear especially when port is randomly generated. It is 
> better to set the server name when building the server and use the server 
> name  as the part of handler thread name 
> {code}
> 2015-05-25 10:43:40,181 INFO  [IPC Server handler 0 on 58849] 
> history.HistoryEventHandler 
> (HistoryEventHandler.java:handleCriticalEvent(110)) - 
> [HISTORY][DAG:dag_1432521818638_0001_1][Event:DAG_SUBMITTED]: 
> dagID=dag_1432521818638_0001_1, submitTime=1432521820100
> 2015-05-25 10:43:40,200 INFO  [IPC Server handler 0 on 58849] impl.DAGImpl 
> (DAGImpl.java:assignDAGScheduler(1360)) - Using DAG Scheduler: 
> org.apache.tez.dag.app.dag.impl.DAGSchedulerNaturalOrderControlled
> 2015-05-25 10:43:40,201 INFO  [IPC Server handler 0 on 58849] h
> {code}



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

[jira] [Created] (HADOOP-12028) Allow to set handler thread name when building IPC Server

2015-05-24 Thread Jeff Zhang (JIRA) 
Jeff Zhang created HADOOP-12028:
---

 Summary: Allow to set handler thread name when building IPC Server
 Key: HADOOP-12028
 URL: https://issues.apache.org/jira/browse/HADOOP-12028
 Project: Hadoop Common
  Issue Type: Improvement
Affects Versions: 2.7.0
Reporter: Jeff Zhang


Currently IPC use the server port to differentiate it with other IPC server. 
This is not very clear especially when port is randomly generated. It is better 
to set the server name when building the server and use the server name  as the 
part of handler thread name 
{code}
2015-05-25 10:43:40,181 INFO  [IPC Server handler 0 on 58849] 
history.HistoryEventHandler (HistoryEventHandler.java:handleCriticalEvent(110)) 
- [HISTORY][DAG:dag_1432521818638_0001_1][Event:DAG_SUBMITTED]: 
dagID=dag_1432521818638_0001_1, submitTime=1432521820100
2015-05-25 10:43:40,200 INFO  [IPC Server handler 0 on 58849] impl.DAGImpl 
(DAGImpl.java:assignDAGScheduler(1360)) - Using DAG Scheduler: 
org.apache.tez.dag.app.dag.impl.DAGSchedulerNaturalOrderControlled
2015-05-25 10:43:40,201 INFO  [IPC Server handler 0 on 58849] h
{code}



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

[jira] [Updated] (HADOOP-12028) Allow to set handler thread name when building IPC Server

2015-05-24 Thread Jeff Zhang (JIRA) 

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

Jeff Zhang updated HADOOP-12028:

Priority: Minor  (was: Major)

> Allow to set handler thread name when building IPC Server
> -
>
> Key: HADOOP-12028
> URL: https://issues.apache.org/jira/browse/HADOOP-12028
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.7.0
>Reporter: Jeff Zhang
>Priority: Minor
>
> Currently IPC use the server port to differentiate it with other IPC server. 
> This is not very clear especially when port is randomly generated. It is 
> better to set the server name when building the server and use the server 
> name  as the part of handler thread name 
> {code}
> 2015-05-25 10:43:40,181 INFO  [IPC Server handler 0 on 58849] 
> history.HistoryEventHandler 
> (HistoryEventHandler.java:handleCriticalEvent(110)) - 
> [HISTORY][DAG:dag_1432521818638_0001_1][Event:DAG_SUBMITTED]: 
> dagID=dag_1432521818638_0001_1, submitTime=1432521820100
> 2015-05-25 10:43:40,200 INFO  [IPC Server handler 0 on 58849] impl.DAGImpl 
> (DAGImpl.java:assignDAGScheduler(1360)) - Using DAG Scheduler: 
> org.apache.tez.dag.app.dag.impl.DAGSchedulerNaturalOrderControlled
> 2015-05-25 10:43:40,201 INFO  [IPC Server handler 0 on 58849] h
> {code}



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

[jira] [Commented] (HADOOP-10909) Add more documents about command "daemonlog"

2015-02-11 Thread Jeff Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-10909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316223#comment-14316223
 ] 

Jeff Zhang commented on HADOOP-10909:
-

Sure, no problem

> Add more documents about command "daemonlog"
> 
>
> Key: HADOOP-10909
> URL: https://issues.apache.org/jira/browse/HADOOP-10909
> Project: Hadoop Common
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Jeff Zhang
>
> In the current document, it does not explain the argument "name" means. 
> People without java knowledge would think it as process name, such as 
> NameNode or DataNode, but actually it is class name. So I suggest to add more 
> document about the "daemonlog" to explain more about the arguments.
> PS: I only find the document on official site (Programming Guide -- Commands 
> Guide), but did not found the document in trunk. Anybody know where's the 
> document of Commands Guide ?



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

[jira] Updated: (HADOOP-6957) Return bindAdrress directly rather than get it from ServerSocketChannel in Listener's getAddress() method

2010-09-18 Thread Jeff Zhang (JIRA) 

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

Jeff Zhang updated HADOOP-6957:
---

Attachment: HADOOP-6957.patch

> Return bindAdrress directly rather than get it from ServerSocketChannel in 
> Listener's getAddress() method
> -
>
> Key: HADOOP-6957
> URL: https://issues.apache.org/jira/browse/HADOOP-6957
> Project: Hadoop Common
>  Issue Type: Improvement
>  Components: ipc
>Reporter: Jeff Zhang
>Priority: Minor
> Attachments: HADOOP-6957.patch
>
>
> I am trying to make Pseudo-Distributed hadoop can been accessed by outside, I 
> change the fs.default.name to 0.0.0.0.:9000 , but still failed. Finally I 
> found that the problem is caused by the Listener's getAddress() in 
> Server.java.  It return Inet6Address format (hdfs://0:0:0:0:0:0:0:0:9000) 
> rather than Inet4Address, I write a blog for the details 
> (http://zjffdu.appspot.com/?p=17001)
> And since the class member "address" is binded to "ServerSocketChannel", then 
> it will be easier to return the address directly rather than get it from 
> ServerSocketChannel.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (HADOOP-6957) Return bindAdrress directly rather than get it from ServerSocketChannel in Listener's getAddress() method

2010-09-18 Thread Jeff Zhang (JIRA) 
Return bindAdrress directly rather than get it from ServerSocketChannel in 
Listener's getAddress() method
-

 Key: HADOOP-6957
 URL: https://issues.apache.org/jira/browse/HADOOP-6957
 Project: Hadoop Common
  Issue Type: Improvement
  Components: ipc
Reporter: Jeff Zhang
Priority: Minor


I am trying to make Pseudo-Distributed hadoop can been accessed by outside, I 
change the fs.default.name to 0.0.0.0.:9000 , but still failed. Finally I found 
that the problem is caused by the Listener's getAddress() in Server.java.  It 
return Inet6Address format (hdfs://0:0:0:0:0:0:0:0:9000) rather than 
Inet4Address, I write a blog for the details 
(http://zjffdu.appspot.com/?p=17001)

And since the class member "address" is binded to "ServerSocketChannel", then 
it will be easier to return the address directly rather than get it from 
ServerSocketChannel.

 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (HADOOP-6866) Tool interface should also support getUsage()

2010-07-19 Thread Jeff Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889792#action_12889792
 ] 

Jeff Zhang commented on HADOOP-6866:


This is a good point, but I concern that it will bring in incompatibility 
problem.  It will force the users who use the old Tool interface to add the 
getUsage() method.




> Tool interface should also support getUsage()
> -
>
> Key: HADOOP-6866
> URL: https://issues.apache.org/jira/browse/HADOOP-6866
> Project: Hadoop Common
>  Issue Type: Improvement
>Reporter: Amar Kamat
>
> Currently each and every _tool_ implementing the {{Tool}} interface is forced 
> to manage their usage string. Since its a common piece of code, its better we 
> factor it out. This can be useful in the following ways
> # A proper lib like support for usage strings
> # Forcing _tools_ (implementers of {{Tool}}) to expose their usage string
> # Test cases can now use these well defined and exposed usage strings to test

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.