[jira] [Resolved] (HADOOP-19109) Fix metrics description
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu resolved HADOOP-19109.
-
Resolution: Not A Problem
> Fix metrics description
> ---
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
>Affects Versions: 3.3.0, 3.3.4
>Reporter: Xiaobao Wu
>Priority: Minor
> Labels: pull-request-available
>
> This description of the RpcLockWaitTimeNumOps metrics seems to be incorrect：
> {code:java}
> | `RpcQueueTimeNumOps` | Total number of RPC calls |
> | `RpcQueueTimeAvgTime` | Average queue time in milliseconds |
> | `RpcLockWaitTimeNumOps` | Total number of RPC calls (same as
> RpcQueueTimeNumOps) |{code}
> I think the description of this metrics should be more clear：
> {code:java}
> | `RpcLockWaitTimeNumOps` | Total number of waiting for lock acquisition
> |{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-19109) Fix metrics description
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu updated HADOOP-19109:
Affects Version/s: 3.3.4
Description:
This description of the RpcLockWaitTimeNumOps metrics seems to be incorrect：
{code:java}
| `RpcQueueTimeNumOps` | Total number of RPC calls |
| `RpcQueueTimeAvgTime` | Average queue time in milliseconds |
| `RpcLockWaitTimeNumOps` | Total number of RPC calls (same as
RpcQueueTimeNumOps) |{code}
I think the description of this metrics should be more clear：
{code:java}
| `RpcLockWaitTimeNumOps` | Total number of waiting for lock acquisition |{code}
was:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
> Fix metrics description
> ---
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
>Affects Versions: 3.3.0, 3.3.4
>Reporter: Xiaobao Wu
>Priority: Minor
> Labels: pull-request-available
>
> This description of the RpcLockWaitTimeNumOps metrics seems to be incorrect：
> {code:java}
> | `RpcQueueTimeNumOps` | Total number of RPC calls |
> | `RpcQueueTimeAvgTime` | Average queue time in milliseconds |
> | `RpcLockWaitTimeNumOps` | Total number of RPC calls (same as
> RpcQueueTimeNumOps) |{code}
> I think the description of this metrics should be more clear：
> {code:java}
> | `RpcLockWaitTimeNumOps` | Total number of waiting for lock acquisition
> |{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-19109) Fix metrics description
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu updated HADOOP-19109:
Summary: Fix metrics description (was: checkPermission should not ignore
original AccessControlException )
> Fix metrics description
> ---
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Xiaobao Wu
>Priority: Minor
> Labels: pull-request-available
>
> In the environment where the *Ranger-HDFS* plugin is enabled, I look at the
> log information of *AccessControlException* caused by the *du.* I find that
> the printed log information is not accurate, because the original
> AccessControlException is ignored by checkPermission, which is not conducive
> to judging the real situation of the AccessControlException . At least part
> of the original log information should be printed.
> AccessControlException information currently printed：
> {code:java}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=test,access=READ_EXECUTE,
> inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
> The original AccessControlException information printed：
> {code:java}
> org.apache.hadoop.security.AccessControlException: Permission denied:
> user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx---
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
> {code}
> From the comparison results of the above log information, it can be seen that
> the inode information and the exception stack printed by the log are not
> accurate.
> Later, the *inode* information prompted by the original
> AccessControlException log information makes me realize that the Ranger-HDFS
> plug-in in the current environment is not incorporated into RANGER-2297, so I
> think it is necessary to prompt this part of the log information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-19109) checkPermission should not ignore original AccessControlException
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu updated HADOOP-19109:
Component/s: (was: hdfs-client)
> checkPermission should not ignore original AccessControlException
> --
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Xiaobao Wu
>Priority: Minor
> Labels: pull-request-available
>
> In the environment where the *Ranger-HDFS* plugin is enabled, I look at the
> log information of *AccessControlException* caused by the *du.* I find that
> the printed log information is not accurate, because the original
> AccessControlException is ignored by checkPermission, which is not conducive
> to judging the real situation of the AccessControlException . At least part
> of the original log information should be printed.
> AccessControlException information currently printed：
> {code:java}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=test,access=READ_EXECUTE,
> inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
> The original AccessControlException information printed：
> {code:java}
> org.apache.hadoop.security.AccessControlException: Permission denied:
> user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx---
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
> {code}
> From the comparison results of the above log information, it can be seen that
> the inode information and the exception stack printed by the log are not
> accurate.
> Later, the *inode* information prompted by the original
> AccessControlException log information makes me realize that the Ranger-HDFS
> plug-in in the current environment is not incorporated into RANGER-2297, so I
> think it is necessary to prompt this part of the log information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-19109) checkPermission should not ignore original AccessControlException
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu updated HADOOP-19109:
Description:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
was:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx--- at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
> checkPermission should not ignore original AccessControlException
> --
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: hdfs-client
>Affects Versions: 3.3.0
>Reporter: Xiaobao Wu
>Priority: Minor
>
> In the environment where the *Ranger-HDFS* plugin is enabled, I look at the
> log information of *AccessControlException* caused by the *du.* I find that
> the printed log information is not accurate, because the original
> AccessControlException is ignored by checkPermission, which is not conducive
> to judging the real situation of the AccessControlException . At least part
> of the original log information should be printed.
> AccessControlException information currently printed：
> {code:java}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=test,access=READ_EXECUTE,
> inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
> The original AccessControlException information printed：
> {code:java}
> org.apache.hadoop.security.AccessControlException: Permission denied:
> user=test,access=READ_EXECUTE,
[jira] [Updated] (HADOOP-19109) checkPermission should not ignore original AccessControlException
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu updated HADOOP-19109:
Description:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx--- at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
was:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx--- at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
> checkPermission should not ignore original AccessControlException
> --
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: hdfs-client
>Affects Versions: 3.3.0
>Reporter: Xiaobao Wu
>Priority: Minor
>
> In the environment where the *Ranger-HDFS* plugin is enabled, I look at the
> log information of *AccessControlException* caused by the *du.* I find that
> the printed log information is not accurate, because the original
> AccessControlException is ignored by checkPermission, which is not conducive
> to judging the real situation of the AccessControlException . At least part
> of the original log information should be printed.
> AccessControlException information currently printed：
> {code:java}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=test,access=READ_EXECUTE,
> inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
>
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
> The original AccessControlException information printed：
> {code:java}
> org.apache.hadoop.security.AccessControlException: Permission denied:
> user=test,access=READ_EXECUTE,
[jira] [Updated] (HADOOP-19109) checkPermission should not ignore original AccessControlException
[
https://issues.apache.org/jira/browse/HADOOP-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobao Wu updated HADOOP-19109:
Description:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
was:
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
> checkPermission should not ignore original AccessControlException
> --
>
> Key: HADOOP-19109
> URL: https://issues.apache.org/jira/browse/HADOOP-19109
> Project: Hadoop Common
> Issue Type: Improvement
> Components: hdfs-client
>Affects Versions: 3.3.0
>Reporter: Xiaobao Wu
>Priority: Minor
>
> In the environment where the *Ranger-HDFS* plugin is enabled, I look at the
> log information of *AccessControlException* caused by the *du.* I find that
> the printed log information is not accurate, because the original
> AccessControlException is ignored by checkPermission, which is not conducive
> to judging the real situation of the AccessControlException . At least part
> of the original log information should be printed.
> AccessControlException information currently printed：
> {code:java}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=test,access=READ_EXECUTE,
> inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
> The original AccessControlException information printed：
> {code:java}
> org.apache.hadoop.security.AccessControlException: Permission denied:
> user=test,access=READ_EXECUTE,
[jira] [Created] (HADOOP-19109) checkPermission should not ignore original AccessControlException
Xiaobao Wu created HADOOP-19109:
---
Summary: checkPermission should not ignore original
AccessControlException
Key: HADOOP-19109
URL: https://issues.apache.org/jira/browse/HADOOP-19109
Project: Hadoop Common
Issue Type: Improvement
Components: hdfs-client
Affects Versions: 3.3.0
Reporter: Xiaobao Wu
In the environment where the *Ranger-HDFS* plugin is enabled, I look at the log
information of *AccessControlException* caused by the *du.* I find that the
printed log information is not accurate, because the original
AccessControlException is ignored by checkPermission, which is not conducive to
judging the real situation of the AccessControlException . At least part of
the original log information should be printed.
AccessControlException information currently printed：
{code:java}
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
Permission denied: user=test,access=READ_EXECUTE,
inode="/warehouse/tablespace/managed/hive/test.db/stu/dt=2024-01-17":hive:hadoop:drwxrwx---
at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:226){code}
The original AccessControlException information printed：
{code:java}
org.apache.hadoop.security.AccessControlException: Permission denied:
user=test,access=READ_EXECUTE, inode="dt=2024-01-17":hive:hadoop:drwxrwx--- at
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:400)
{code}
>From the comparison results of the above log information, it can be seen that
>the inode information and the exception stack printed by the log are not
>accurate.
Later, the *inode* information prompted by the original AccessControlException
log information makes me realize that the Ranger-HDFS plug-in in the current
environment is not incorporated into RANGER-2297, so I think it is necessary to
prompt this part of the log information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
