[
https://issues.apache.org/jira/browse/HADOOP-8661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431262#comment-13431262
]
Robert Joseph Evans commented on HADOOP-8661:
---------------------------------------------
The issue is not with the contents of the stack trace. The stack trace is
fine. The issue is that the message of the exception includes the stack trace.
For example:
{code}
try {
Path p = new Path(file);
FileSystem fs = p.getFileSystem(conf);
fs.delete(p, true);
} catch( IOException e) {
System.err.println("MESSAGE: " +e.getMessage());
}
{code}
If this is run on 1.0.2 and it gets a permission denied error you only get
something like
{noformat}
MESSAGE: Permission denied: user=notme, access=EXECUTE,
inode="/user/me/test":me:supergroup:d---------
{noformat}
But on trunk, 2.0, and 0.23 you get
{noformat}
MESSAGE: Permission denied: user=notme, access=EXECUTE,
inode="/user/me/test":me:supergroup:d---------
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:205)
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkTraverse(FSPermissionChecker.java:161)
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:128)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkPermission(FSNamesystem.java:3572)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.deleteInternal(FSNamesystem.java:1931)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete(FSNamesystem.java:1896)
at
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.delete(NameNodeRpcServer.java:539)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.hadoop.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:394)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1528)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1524)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1177)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1522)
{noformat}
Oozie tries to save the message in its database, but when the full stack trace
is included it gets very large and can cause issues.
> Stack Trace in Exception.getMessage causing oozie DB to have issues
> -------------------------------------------------------------------
>
> Key: HADOOP-8661
> URL: https://issues.apache.org/jira/browse/HADOOP-8661
> Project: Hadoop Common
> Issue Type: Bug
> Components: ipc
> Affects Versions: 0.23.3, 2.0.0-alpha, 3.0.0
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
>
> It looks like all exceptions produced by RemoteException include the full
> stack trace of the original exception in the message. This is causing issues
> for oozie because they store the message in their database and it is getting
> very large. This appears to be a regression from 1.0 behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
