[jira] [Resolved] (HDFS-7532) dncp_block_verification.log.prev too large

2015-01-01 Thread Harsh J (JIRA) 

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

Harsh J resolved HDFS-7532.
---
Resolution: Duplicate

Should be eventually fixed via HDFS-7430.

Yes, you may shutdown the affected DN temporarily, delete these files and start 
it back up.

> dncp_block_verification.log.prev too large
> --
>
> Key: HDFS-7532
> URL: https://issues.apache.org/jira/browse/HDFS-7532
> Project: Hadoop HDFS
>  Issue Type: Bug
>Reporter: Arti Wadhwani
>Priority: Blocker
>
> Hi, 
> Using hadoop version :  Hadoop 2.0.0-cdh4.7.0
> can see on one datanode, dncp_block_verification.log.prev is too  large. 
> Is it safe to delete this file? 
> {noformat}
> -rw-r--r-- 1 hdfs hdfs 1166438426181 Oct 31 09:34 
> dncp_block_verification.log.prev
> -rw-r--r-- 1 hdfs hdfs 138576163 Dec 15 22:16 
> dncp_block_verification.log.curr
> {noformat}
> This is similar to HDFS-6114 but that is for dncp_block_verification.log.curr 
> file. 
> Thanks,
> Arti Wadhwani



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

[jira] [Created] (HDFS-7580) NN -> JN communication should use reusable authentication methods

2015-01-01 Thread Harsh J (JIRA) 
Harsh J created HDFS-7580:
-

 Summary: NN -> JN communication should use reusable authentication 
methods
 Key: HDFS-7580
 URL: https://issues.apache.org/jira/browse/HDFS-7580
 Project: Hadoop HDFS
  Issue Type: Improvement
  Components: journal-node, namenode
Affects Versions: 2.5.0
Reporter: Harsh J


It appears that NNs talk to JNs via general SaslRPC in secure mode, causing all 
requests to be carried out with a kerberos authentication. This can cause 
delays and occasionally NN failures if the KDC used does not respond in its 
default timeout period (30s, whereas the QJM writes come with default of 20s).



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

[jira] [Resolved] (HDFS-7493) removedDst should be checked against null in finally block of FSDirRenameOp#unprotectedRenameTo()

2015-01-01 Thread Ted Yu (JIRA) 

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

Ted Yu resolved HDFS-7493.
--
Resolution: Duplicate

Dup of HDFS-7538

> removedDst should be checked against null in finally block of 
> FSDirRenameOp#unprotectedRenameTo()
> -
>
> Key: HDFS-7493
> URL: https://issues.apache.org/jira/browse/HDFS-7493
> Project: Hadoop HDFS
>  Issue Type: Bug
>Reporter: Ted Yu
>Priority: Minor
>
> {code}
>   removedDst = dstIIP.getLastINode();
>   undoRemoveDst = true;
> {code}
> If removedDst is null, the following code in finally block may result in NPE:
> {code}
> if (dstParent.isDirectory() &&
> dstParent.asDirectory().isWithSnapshot()) {
>   dstParent.asDirectory().undoRename4DstParent(removedDst,
>   dstIIP.getLatestSnapshotId());
> {code}



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

Jenkins build is back to normal : Hadoop-Hdfs-trunk #1991

2015-01-01 Thread Apache Jenkins Server 
See