You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-commits@hadoop.apache.org by ma...@apache.org on 2011/12/01 07:03:19 UTC
svn commit: r1208962 [2/2] -
/hadoop/common/branches/branch-1/src/docs/releasenotes.html
Modified: hadoop/common/branches/branch-1/src/docs/releasenotes.html
URL: http://svn.apache.org/viewvc/hadoop/common/branches/branch-1/src/docs/releasenotes.html?rev=1208962&r1=1208961&r2=1208962&view=diff
==============================================================================
--- hadoop/common/branches/branch-1/src/docs/releasenotes.html (original)
+++ hadoop/common/branches/branch-1/src/docs/releasenotes.html Thu Dec 1 06:03:19 2011
@@ -2,7 +2,7 @@
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<title>Hadoop 0.20.1 Release Notes</title>
+<title>Hadoop 1.0.0 Release Notes</title>
<STYLE type="text/css">
H1 {font-family: sans-serif}
H2 {font-family: sans-serif; margin-left: 7mm}
@@ -10,17 +10,942 @@
</STYLE>
</head>
<body>
-<h1>Hadoop 0.20.1 Release Notes</h1>
- These release notes include new developer and user-facing incompatibilities, features, and major improvements. The table below is sorted by Component.
+<h1>Hadoop 1.0.0 Release Notes</h1>
+ These release notes include new developer and user-facing incompatibilities, features, and major improvements.
- <a name="changes"></a>
-<h2>Changes Since Hadoop 0.20.0</h2>
+<a name="changes"/>
+<h2>Changes since Hadoop 0.20.205.0</h2>
-<h3>Common</h3>
+<h3>Jiras with Release Notes (describe major or incompatible changes)</h3>
+<ul>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7728">HADOOP-7728</a>.
+ Major bug reported by rramya and fixed by rramya (conf)<br>
+ <b>hadoop-setup-conf.sh should be modified to enable task memory manager</b><br>
+ <blockquote> Enable task memory management to be configurable via hadoop config setup script.
+
+
+</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7740">HADOOP-7740</a>.
+ Minor bug reported by arpitgupta and fixed by arpitgupta (conf)<br>
+ <b>security audit logger is not on by default, fix the log4j properties to enable the logger</b><br>
+ <blockquote> Fixed security audit logger configuration. (Arpit Gupta via Eric Yang)
+
+
+</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-617">HDFS-617</a>.
+ Major improvement reported by kzhang and fixed by kzhang (hdfs client, name-node)<br>
+ <b>Support for non-recursive create() in HDFS</b><br>
+ <blockquote> New DFSClient.create(...) allows option of not creating missing parent(s).
+
+
+</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2246">HDFS-2246</a>.
+ Major improvement reported by sanjay.radia and fixed by jnp <br>
+ <b>Shortcut a local client reads to a Datanodes files directly</b><br>
+ <blockquote> 1. New configurations
<br/>
+
+a. dfs.block.local-path-access.user is the key in datanode configuration to specify the user allowed to do short circuit read.
<br/>
+
+b. dfs.client.read.shortcircuit is the key to enable short circuit read at the client side configuration.
<br/>
+
+c. dfs.client.read.shortcircuit.skip.checksum is the key to bypass checksum check at the client side.
<br/>
+
+2. By default none of the above are enabled and short circuit read will not kick in.
<br/>
+
+3. If security is on, the feature can be used only for user that has kerberos credentials at the client, therefore map reduce tasks cannot benefit from it in general.
<br/>
+
+
+</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2316">HDFS-2316</a>.
+ Major new feature reported by szetszwo and fixed by szetszwo <br>
+ <b>[umbrella] webhdfs: a complete FileSystem implementation for accessing HDFS over HTTP</b><br>
+ <blockquote> Provide webhdfs as a complete FileSystem implementation for accessing HDFS over HTTP.
<br/>
+
+Previous hftp feature was a read-only FileSystem and does not provide "write" accesses.
+</blockquote></li>
+
+</ul>
+
+
+<h3>Other Jiras (describe bug fixes and minor changes)</h3>
+<ul>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-5124">HADOOP-5124</a>.
+ Major improvement reported by hairong and fixed by hairong <br>
+ <b>A few optimizations to FsNamesystem#RecentInvalidateSets</b><br>
+ <blockquote>This jira proposes a few optimization to FsNamesystem#RecentInvalidateSets:<br>1. when removing all replicas of a block, it does not traverse all nodes in the map. Instead it traverse only the nodes that the block is located.<br>2. When dispatching blocks to datanodes in ReplicationMonitor. It randomly chooses a predefined number of datanodes and dispatches blocks to those datanodes. This strategy provides fairness to all datanodes. The current strategy always starts from the first datanode.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-6840">HADOOP-6840</a>.
+ Minor improvement reported by nspiegelberg and fixed by jnp (fs, io)<br>
+ <b>Support non-recursive create() in FileSystem & SequenceFile.Writer</b><br>
+ <blockquote>The proposed solution for HBASE-2312 requires the sequence file to handle a non-recursive create. This is already supported by HDFS, but needs to have an equivalent FileSystem & SequenceFile.Writer API.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-6886">HADOOP-6886</a>.
+ Minor improvement reported by nspiegelberg and fixed by (fs)<br>
+ <b>LocalFileSystem Needs createNonRecursive API</b><br>
+ <blockquote>While running sanity check tests for HBASE-2312, I noticed that HDFS-617 did not include createNonRecursive() support for the LocalFileSystem. This is a problem for HBase, which allows the user to run over the LocalFS instead of HDFS for local cluster testing. I think this only affects 0.20-append, but may affect the trunk based upon how exactly FileContext handles non-recursive creates.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7664">HADOOP-7664</a>.
+ Minor improvement reported by raviprak and fixed by raviprak (conf)<br>
+ <b>o.a.h.conf.Configuration complains of overriding final parameter even if the value with which its attempting to override is the same. </b><br>
+ <blockquote>o.a.h.conf.Configuration complains of overriding final parameter even if the value with which its attempting to override is the same. </blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7765">HADOOP-7765</a>.
+ Major bug reported by eyang and fixed by eyang (build)<br>
+ <b>Debian package contain both system and tar ball layout</b><br>
+ <blockquote>When packaging is invoked as "ant clean tar deb". The system creates both system layout and tarball layout in the same build directory. Debian packaging target would pick up files for both layouts. The end result of using produced debian package built this way, would end up README.txt LICENSE.txt, and jar files in /usr.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7784">HADOOP-7784</a>.
+ Major bug reported by arpitgupta and fixed by eyang <br>
+ <b>secure datanodes fail to come up stating jsvc not found </b><br>
+ <blockquote>building 205.1 and trying to startup a secure dn leads to the following<br><br>/usr/libexec/../bin/hadoop: line 386: /usr/libexec/../libexec/jsvc.amd64: No such file or directory<br>/usr/libexec/../bin/hadoop: line 386: exec: /usr/libexec/../libexec/jsvc.amd64: cannot execute: No such file or directory</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7804">HADOOP-7804</a>.
+ Major improvement reported by arpitgupta and fixed by arpitgupta (conf)<br>
+ <b>enable hadoop config generator to set dfs.block.local-path-access.user to enable short circuit read</b><br>
+ <blockquote>we have a new config that allows to select which user can have access for short circuit read. We should make that configurable through the config generator scripts.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7810">HADOOP-7810</a>.
+ Blocker bug reported by johnvijoe and fixed by johnvijoe <br>
+ <b>move hadoop archive to core from tools</b><br>
+ <blockquote>"The HadoopArchieves classes are included in the $HADOOP_HOME/hadoop_tools.jar, but this file is not found in `hadoop classpath`.<br><br>A Pig script using HCatalog's dynamic partitioning with HAR enabled will therefore fail if a jar with HAR is not included in the pig call's '-cp' and '-Dpig.additional.jars' arguments."<br><br>I am not aware of any reason to not include hadoop-tools.jar in 'hadoop classpath'. Will attach a patch soon.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7815">HADOOP-7815</a>.
+ Minor bug reported by rramya and fixed by rramya (conf)<br>
+ <b>Map memory mb is being incorrectly set by hadoop-setup-conf.sh</b><br>
+ <blockquote>HADOOP-7728 enabled task memory management to be configurable in the hadoop-setup-conf.sh. However, the default value for mapred.job.map.memory.mb is being set incorrectly.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7816">HADOOP-7816</a>.
+ Major bug reported by davet and fixed by davet <br>
+ <b>Allow HADOOP_HOME deprecated warning suppression based on config specified in hadoop-env.sh</b><br>
+ <blockquote>Move suppression check for "Warning: $HADOOP_HOME is deprecated" to after sourcing of hadoop-env.sh so that people can set HADOOP_HOME_WARN_SUPPRESS inside the config.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7853">HADOOP-7853</a>.
+ Blocker bug reported by daryn and fixed by daryn (security)<br>
+ <b>multiple javax security configurations cause conflicts</b><br>
+ <blockquote>Both UGI and the SPNEGO KerberosAuthenticator set the global javax security configuration. SPNEGO stomps on UGI's security config which leads to kerberos/SASL authentication errors.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7854">HADOOP-7854</a>.
+ Critical bug reported by daryn and fixed by daryn (security)<br>
+ <b>UGI getCurrentUser is not synchronized</b><br>
+ <blockquote>Sporadic {{ConcurrentModificationExceptions}} are originating from {{UGI.getCurrentUser}} when it needs to create a new instance. The problem was specifically observed in a JT under heavy load when a post-job cleanup is accessing the UGI while a new job is being processed.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7865">HADOOP-7865</a>.
+ Major bug reported by jnp and fixed by jnp <br>
+ <b>Test Failures in 1.0.0 hdfs/common</b><br>
+ <blockquote>Following tests in hdfs and common are failing<br>1. TestFileAppend2<br>2. TestFileConcurrentReader<br>3. TestDoAsEffectiveUser </blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7869">HADOOP-7869</a>.
+ Critical bug reported by owen.omalley and fixed by owen.omalley (scripts)<br>
+ <b>HADOOP_HOME warning happens all of the time</b><br>
+ <blockquote>With HADOOP-7816, the check for HADOOP_HOME has moved after it is set by hadoop-config so that it always happens unless HADOOP_HOME_WARN_SUPPRESS is set in hadoop-env or the environment.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-611">HDFS-611</a>.
+ Major bug reported by dhruba and fixed by zshao (data-node)<br>
+ <b>Heartbeats times from Datanodes increase when there are plenty of blocks to delete</b><br>
+ <blockquote>I am seeing that when we delete a large directory that has plenty of blocks, the heartbeat times from datanodes increase significantly from the normal value of 3 seconds to as large as 50 seconds or so. The heartbeat thread in the Datanode deletes a bunch of blocks sequentially, this causes the heartbeat times to increase.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1257">HDFS-1257</a>.
+ Major bug reported by rvadali and fixed by eepayne (name-node)<br>
+ <b>Race condition on FSNamesystem#recentInvalidateSets introduced by HADOOP-5124</b><br>
+ <blockquote>HADOOP-5124 provided some improvements to FSNamesystem#recentInvalidateSets. But it introduced unprotected access to the data structure recentInvalidateSets. Specifically, FSNamesystem.computeInvalidateWork accesses recentInvalidateSets without read-lock protection. If there is concurrent activity (like reducing replication on a file) that adds to recentInvalidateSets, the name-node crashes with a ConcurrentModificationException.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1943">HDFS-1943</a>.
+ Blocker bug reported by weiyj and fixed by mattf (scripts)<br>
+ <b>fail to start datanode while start-dfs.sh is executed by root user</b><br>
+ <blockquote>When start-dfs.sh is run by root user, we got the following error message:<br># start-dfs.sh<br>Starting namenodes on [localhost ]<br>localhost: namenode running as process 2556. Stop it first.<br>localhost: starting datanode, logging to /usr/hadoop/hadoop-common-0.23.0-SNAPSHOT/bin/../logs/hadoop-root-datanode-cspf01.out<br>localhost: Unrecognized option: -jvm<br>localhost: Could not create the Java virtual machine.<br><br>The -jvm options should be passed to jsvc when we starting a secure<br>datanode, but it still pa...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2065">HDFS-2065</a>.
+ Major bug reported by bharathm and fixed by umamaheswararao <br>
+ <b>Fix NPE in DFSClient.getFileChecksum</b><br>
+ <blockquote>The following code can throw NPE if callGetBlockLocations returns null.<br><br>If server returns null <br><br>{code}<br> List<LocatedBlock> locatedblocks<br> = callGetBlockLocations(namenode, src, 0, Long.MAX_VALUE).getLocatedBlocks();<br>{code}<br><br>The right fix for this is server should throw right exception.<br><br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2346">HDFS-2346</a>.
+ Blocker bug reported by umamaheswararao and fixed by lakshman (test)<br>
+ <b>TestHost2NodesMap & TestReplicasMap will fail depending upon execution order of test methods</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2416">HDFS-2416</a>.
+ Major sub-task reported by arpitgupta and fixed by jnp <br>
+ <b>distcp with a webhdfs uri on a secure cluster fails</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2424">HDFS-2424</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs liststatus json does not convert to a valid xml document</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2427">HDFS-2427</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs mkdirs api call creates path with 777 permission, we should default it to 755</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2428">HDFS-2428</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs api parameter validation should be better</b><br>
+ <blockquote>PUT Request: http://localhost:50070/webhdfs/some_path?op=MKDIRS&permission=955<br><br>Exception returned<br><br><br>HTTP/1.1 500 Internal Server Error<br>{"RemoteException":{"className":"com.sun.jersey.api.ParamException$QueryParamException","message":"java.lang.NumberFormatException: For input string: \"955\""}} <br><br><br>We should return a 400 with appropriate error message</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2432">HDFS-2432</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs setreplication api should return a 403 when called on a directory</b><br>
+ <blockquote>Currently the set replication api on a directory leads to a 200.<br><br>Request URI http://NN:50070/webhdfs/tmp/webhdfs_data/dir_replication_tests?op=SETREPLICATION&replication=5<br>Request Method: PUT<br>Status Line: HTTP/1.1 200 OK<br>Response Content: {"boolean":false}<br><br>Since we can determine that this call did not succeed (boolean=false) we should rather just return a 403</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2439">HDFS-2439</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs open an invalid path leads to a 500 which states a npe, we should return a 404 with appropriate error message</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2441">HDFS-2441</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs returns two content-type headers</b><br>
+ <blockquote>$ curl -i "http://localhost:50070/webhdfs/path?op=GETFILESTATUS"<br>HTTP/1.1 200 OK<br>Content-Type: text/html; charset=utf-8<br>Expires: Thu, 01-Jan-1970 00:00:00 GMT<br>........<br>Content-Type: application/json<br>Transfer-Encoding: chunked<br>Server: Jetty(6.1.26)<br><br><br>It should only return one content type header = application/json</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2450">HDFS-2450</a>.
+ Major bug reported by rajsaha and fixed by daryn <br>
+ <b>Only complete hostname is supported to access data via hdfs://</b><br>
+ <blockquote>If my complete hostname is host1.abc.xyz.com, only complete hostname must be used to access data via hdfs://<br><br>I am running following in .20.205 Client to get data from .20.205 NN (host1)<br>$hadoop dfs -copyFromLocal /etc/passwd hdfs://host1/tmp<br>copyFromLocal: Wrong FS: hdfs://host1/tmp, expected: hdfs://host1.abc.xyz.com<br>Usage: java FsShell [-copyFromLocal <localsrc> ... <dst>]<br><br>$hadoop dfs -copyFromLocal /etc/passwd hdfs://host1.abc/tmp/<br>copyFromLocal: Wrong FS: hdfs://host1.blue/tmp/1, exp...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2453">HDFS-2453</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>tail using a webhdfs uri throws an error</b><br>
+ <blockquote>/usr//bin/hadoop --config /etc/hadoop dfs -tail webhdfs://NN:50070/file <br>tail: HTTP_PARTIAL expected, received 200<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2494">HDFS-2494</a>.
+ Major sub-task reported by umamaheswararao and fixed by umamaheswararao (data-node)<br>
+ <b>[webhdfs] When Getting the file using OP=OPEN with DN http address, ESTABLISHED sockets are growing.</b><br>
+ <blockquote>As part of the reliable test,<br>Scenario:<br>Initially check the socket count. ---there are aroud 42 sockets are there.<br>open the file with DataNode http address using op=OPEN request parameter about 500 times in loop.<br>Wait for some time and check the socket count. --- There are thousands of ESTABLISHED sockets are growing. ~2052<br><br>Here is the netstat result:<br><br>C:\Users\uma>netstat | grep 127.0.0.1 | grep ESTABLISHED |wc -l<br>2042<br>C:\Users\uma>netstat | grep 127.0.0.1 | grep ESTABLISHED |wc -l<br>2042<br>C:\...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2501">HDFS-2501</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>add version prefix and root methods to webhdfs</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2527">HDFS-2527</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Remove the use of Range header from webhdfs</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2528">HDFS-2528</a>.
+ Major sub-task reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs rest call to a secure dn fails when a token is sent</b><br>
+ <blockquote>curl -L -u : --negotiate -i "http://NN:50070/webhdfs/v1/tmp/webhdfs_data/file_small_data.txt?op=OPEN"<br><br>the following exception is thrown by the datanode when the redirect happens.<br>{"RemoteException":{"exception":"IOException","javaClassName":"java.io.IOException","message":"Call to failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]"}}<br>...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2539">HDFS-2539</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Support doAs and GETHOMEDIRECTORY in webhdfs</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2540">HDFS-2540</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Change WebHdfsFileSystem to two-step create/append</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2552">HDFS-2552</a>.
+ Major task reported by szetszwo and fixed by szetszwo (documentation)<br>
+ <b>Add WebHdfs Forrest doc</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2590">HDFS-2590</a>.
+ Major bug reported by szetszwo and fixed by szetszwo (documentation)<br>
+ <b>Some links in WebHDFS forrest doc do not work</b><br>
+ <blockquote>Some links are pointing to DistributedFileSystem javadoc but the javadoc of DistributedFileSystem is not generated by default.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2604">HDFS-2604</a>.
+ Minor improvement reported by szetszwo and fixed by szetszwo (data-node, documentation, name-node)<br>
+ <b>Add a log message to show if WebHDFS is enabled</b><br>
+ <blockquote>WebHDFS can be enabled/disabled by the conf key {{dfs.webhdfs.enabled}}. Let's add a log message to show if it is enabled.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-3169">MAPREDUCE-3169</a>.
+ Major improvement reported by tlipcon and fixed by ahmed.radwan (mrv1, mrv2, test)<br>
+ <b>Create a new MiniMRCluster equivalent which only provides client APIs cross MR1 and MR2</b><br>
+ <blockquote>Many dependent projects like HBase, Hive, Pig, etc, depend on MiniMRCluster for writing tests. Many users do as well. MiniMRCluster, however, exposes MR implementation details like the existence of TaskTrackers, JobTrackers, etc, since it was used by MR1 for testing the server implementations as well.<br><br>This JIRA is to create a new interface which could be implemented either by MR1 or MR2 that exposes only the client-side portions of the MR framework. Ideally it would be "recompile-compatible"...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-3374">MAPREDUCE-3374</a>.
+ Major bug reported by rvs and fixed by (task-controller)<br>
+ <b>src/c++/task-controller/configure is not set executable in the tarball and that prevents task-controller from rebuilding</b><br>
+ <blockquote>ant task-controller fails because src/c++/task-controller/configure is not set executable</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-3480">MAPREDUCE-3480</a>.
+ Major bug reported by jnp and fixed by jnp <br>
+ <b>TestJvmReuse fails in 1.0</b><br>
+ <blockquote>TestJvmReuse is failing in apache builds, although it passes in my local machine.</blockquote></li>
+
+</ul>
+
+
+<h2>Changes since Hadoop 0.20.204.0</h2>
+
+<ul>
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-6722">HADOOP-6722</a>.
+ Major bug reported by tlipcon and fixed by tlipcon (util)<br>
+ <b>NetUtils.connect should check that it hasn't connected a socket to itself</b><br>
+ <blockquote>I had no idea this was possible, but it turns out that a TCP connection will be established in the rare case that the local side of the socket binds to the ephemeral port that you later try to connect to. This can present itself in very very rare occasion when an RPC client is trying to connect to a daemon running on the same node, but that daemon is down. To see what I'm talking about, run "while true ; do telnet localhost 60020 ; done" on a multicore box and wait several minutes.<br><br>This can ...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-6833">HADOOP-6833</a>.
+ Blocker bug reported by tlipcon and fixed by tlipcon <br>
+ <b>IPC leaks call parameters when exceptions thrown</b><br>
+ <blockquote>HADOOP-6498 moved the calls.remove() call lower into the SUCCESS clause of receiveResponse(), but didn't put a similar calls.remove into the ERROR clause. So, any RPC call that throws an exception ends up orphaning the Call object in the connection's "calls" hashtable. This prevents cleanup of the connection and is a memory leak for the call parameters.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-6889">HADOOP-6889</a>.
+ Major new feature reported by hairong and fixed by johnvijoe (ipc)<br>
+ <b>Make RPC to have an option to timeout</b><br>
+ <blockquote>Currently Hadoop RPC does not timeout when the RPC server is alive. What it currently does is that a RPC client sends a ping to the server whenever a socket timeout happens. If the server is still alive, it continues to wait instead of throwing a SocketTimeoutException. This is to avoid a client to retry when a server is busy and thus making the server even busier. This works great if the RPC server is NameNode.<br><br>But Hadoop RPC is also used for some of client to DataNode communications, for e...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7119">HADOOP-7119</a>.
+ Major new feature reported by tucu00 and fixed by tucu00 (security)<br>
+ <b>add Kerberos HTTP SPNEGO authentication support to Hadoop JT/NN/DN/TT web-consoles</b><br>
+ <blockquote> Adding support for Kerberos HTTP SPNEGO authentication to the Hadoop web-consoles<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7314">HADOOP-7314</a>.
+ Major improvement reported by naisbitt and fixed by naisbitt <br>
+ <b>Add support for throwing UnknownHostException when a host doesn't resolve</b><br>
+ <blockquote>As part of MAPREDUCE-2489, we need support for having the resolve methods (for DNS mapping) throw UnknownHostExceptions. (Currently, they hide the exception). Since the existing 'resolve' method is ultimately used by several other locations/components, I propose we add a new 'resolveValidHosts' method.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7343">HADOOP-7343</a>.
+ Minor improvement reported by tgraves and fixed by tgraves (test)<br>
+ <b>backport HADOOP-7008 and HADOOP-7042 to branch-0.20-security</b><br>
+ <blockquote>backport HADOOP-7008 and HADOOP-7042 to branch-0.20-security so that we can enable test-patch.sh to have a configured number of acceptable findbugs and javadoc warnings</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7400">HADOOP-7400</a>.
+ Major bug reported by gkesavan and fixed by gkesavan (build)<br>
+ <b>HdfsProxyTests fails when the -Dtest.build.dir and -Dbuild.test is set </b><br>
+ <blockquote>HdfsProxyTests fails when the -Dtest.build.dir and -Dbuild.test is set a dir other than build dir<br><br>test-junit:<br> [copy] Copying 1 file to /home/y/var/builds/thread2/workspace/Cloud-Hadoop-0.20.1xx-Secondary/src/contrib/hdfsproxy/src/test/resources/proxy-config<br> [junit] Running org.apache.hadoop.hdfsproxy.TestHdfsProxy<br> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec<br> [junit] Test org.apache.hadoop.hdfsproxy.TestHdfsProxy FAILED</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7432">HADOOP-7432</a>.
+ Major improvement reported by sherri_chen and fixed by sherri_chen <br>
+ <b>Back-port HADOOP-7110 to 0.20-security</b><br>
+ <blockquote>HADOOP-7110 implemented chmod in the NativeIO library so we can have good performance (ie not fork) and still not be prone to races. This should fix build failures (and probably task failures too).</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7472">HADOOP-7472</a>.
+ Minor improvement reported by kihwal and fixed by kihwal (ipc)<br>
+ <b>RPC client should deal with the IP address changes</b><br>
+ <blockquote>The current RPC client implementation and the client-side callers assume that the hostname-address mappings of servers never change. The resolved address is stored in an immutable InetSocketAddress object above/outside RPC, and the reconnect logic in the RPC Connection implementation also trusts the resolved address that was passed down.<br><br>If the NN suffers a failure that requires migration, it may be started on a different node with a different IP address. In this case, even if the name-addre...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7510">HADOOP-7510</a>.
+ Major improvement reported by daryn and fixed by daryn (security)<br>
+ <b>Tokens should use original hostname provided instead of ip</b><br>
+ <blockquote>Tokens currently store the ip:port of the remote server. This precludes tokens from being used after a host's ip is changed. Tokens should store the hostname used to make the RPC connection. This will enable new processes to use their existing tokens.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7539">HADOOP-7539</a>.
+ Major bug reported by johnvijoe and fixed by johnvijoe <br>
+ <b>merge hadoop archive goodness from trunk to .20</b><br>
+ <blockquote>hadoop archive in branch-0.20-security is outdated. When run recently, it produced some bugs which were all fixed in trunk. This JIRA aims to bring in all these JIRAs to branch-0.20-security.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7594">HADOOP-7594</a>.
+ Major new feature reported by szetszwo and fixed by szetszwo <br>
+ <b>Support HTTP REST in HttpServer</b><br>
+ <blockquote>Provide an API in HttpServer for supporting HTTP REST.<br><br>This is a part of HDFS-2284.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7596">HADOOP-7596</a>.
+ Major bug reported by eyang and fixed by eyang (build)<br>
+ <b>Enable jsvc to work with Hadoop RPM package</b><br>
+ <blockquote>For secure Hadoop 0.20.2xx cluster, datanode can only run with 32 bit jvm because Hadoop only packages 32 bit jsvc. The build process should download proper jsvc versions base on the build architecture. In addition, the shell script should be enhanced to locate hadoop jar files in the proper location.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7599">HADOOP-7599</a>.
+ Major bug reported by eyang and fixed by eyang (scripts)<br>
+ <b>Improve hadoop setup conf script to setup secure Hadoop cluster</b><br>
+ <blockquote>Setting up a secure Hadoop cluster requires a lot of manual setup. The motivation of this jira is to provide setup scripts to automate setup secure Hadoop cluster.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7602">HADOOP-7602</a>.
+ Major bug reported by johnvijoe and fixed by johnvijoe <br>
+ <b>wordcount, sort etc on har files fails with NPE</b><br>
+ <blockquote>wordcount, sort etc on har files fails with NPE@createSocketAddr(NetUtils.java:137). </blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7603">HADOOP-7603</a>.
+ Major bug reported by eyang and fixed by eyang <br>
+ <b>Set default hdfs, mapred uid, and hadoop group gid for RPM packages</b><br>
+ <blockquote> Set hdfs, mapred uid, and hadoop uid to fixed numbers. (Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7610">HADOOP-7610</a>.
+ Major bug reported by eyang and fixed by eyang (scripts)<br>
+ <b>/etc/profile.d does not exist on Debian</b><br>
+ <blockquote>As part of post installation script, there is a symlink created in /etc/profile.d/hadoop-env.sh to source /etc/hadoop/hadoop-env.sh. Therefore, users do not need to configure HADOOP_* environment. Unfortunately, /etc/profile.d only exists in Ubuntu. [Section 9.9 of the Debian Policy|http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9] states:<br><br>{quote}<br>A program must not depend on environment variables to get reasonable defaults. (That's because these environment variables would ha...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7615">HADOOP-7615</a>.
+ Major bug reported by eyang and fixed by eyang (scripts)<br>
+ <b>Binary layout does not put share/hadoop/contrib/*.jar into the class path</b><br>
+ <blockquote>For contrib projects, contrib jar files are not included in HADOOP_CLASSPATH in the binary layout. Several projects jar files should be copied to $HADOOP_PREFIX/share/hadoop/lib for binary deployment. The interesting jar files to include in $HADOOP_PREFIX/share/hadoop/lib are: capacity-scheduler, thriftfs, fairscheduler.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7625">HADOOP-7625</a>.
+ Major bug reported by owen.omalley and fixed by owen.omalley <br>
+ <b>TestDelegationToken is failing in 205</b><br>
+ <blockquote>After the patches on Friday, org.apache.hadoop.hdfs.security.TestDelegationToken is failing.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7626">HADOOP-7626</a>.
+ Major bug reported by eyang and fixed by eyang (scripts)<br>
+ <b>Allow overwrite of HADOOP_CLASSPATH and HADOOP_OPTS</b><br>
+ <blockquote>Quote email from Ashutosh Chauhan:<br><br>bq. There is a bug in hadoop-env.sh which prevents hcatalog server to start in secure settings. Instead of adding classpath, it overrides them. I was not able to verify where the bug belongs to, in HMS or in hadoop scripts. Looks like hadoop-env.sh is generated from hadoop-env.sh.template in installation process by HMS. Hand crafted patch follows:<br><br>bq. - export HADOOP_CLASSPATH=$f<br>bq. +export HADOOP_CLASSPATH=${HADOOP_CLASSPATH}:$f<br><br>bq. -export HADOOP_OPTS=...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7630">HADOOP-7630</a>.
+ Major bug reported by arpitgupta and fixed by eyang (conf)<br>
+ <b>hadoop-metrics2.properties should have a property *.period set to a default value foe metrics</b><br>
+ <blockquote>currently the hadoop-metrics2.properties file does not have a value set for *.period<br><br>This property is useful for metrics to determine when the property will refresh. We should set it to default of 60</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7631">HADOOP-7631</a>.
+ Major bug reported by rramya and fixed by eyang (conf)<br>
+ <b>In mapred-site.xml, stream.tmpdir is mapped to ${mapred.temp.dir} which is undeclared.</b><br>
+ <blockquote>Streaming jobs seem to fail with the following exception:<br><br>{noformat}<br>Exception in thread "main" java.io.IOException: No such file or directory<br> at java.io.UnixFileSystem.createFileExclusively(Native Method)<br> at java.io.File.checkAndCreate(File.java:1704)<br> at java.io.File.createTempFile(File.java:1792)<br> at org.apache.hadoop.streaming.StreamJob.packageJobJar(StreamJob.java:603)<br> at org.apache.hadoop.streaming.StreamJob.setJobConf(StreamJob.java:798)<br> a...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7633">HADOOP-7633</a>.
+ Major bug reported by arpitgupta and fixed by eyang (conf)<br>
+ <b>log4j.properties should be added to the hadoop conf on deploy</b><br>
+ <blockquote>currently the log4j properties are not present in the hadoop conf dir. We should add them so that log rotation happens appropriately and also define other logs that hadoop can generate for example the audit and the auth logs as well as the mapred summary logs etc.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7637">HADOOP-7637</a>.
+ Major bug reported by eyang and fixed by eyang (build)<br>
+ <b>Fair scheduler configuration file is not bundled in RPM</b><br>
+ <blockquote>205 build of tar is fine, but rpm failed with:<br><br>{noformat}<br> [rpm] Processing files: hadoop-0.20.205.0-1<br> [rpm] warning: File listed twice: /usr/libexec<br> [rpm] warning: File listed twice: /usr/libexec/hadoop-config.sh<br> [rpm] warning: File listed twice: /usr/libexec/jsvc.i386<br> [rpm] Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/hadoop_package_build_hortonfo/BUILD<br> [rpm] error: Installed (but unpackaged) file(s) found:<br> [rpm] /etc/hadoop/fai...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7644">HADOOP-7644</a>.
+ Blocker bug reported by owen.omalley and fixed by owen.omalley (security)<br>
+ <b>Fix the delegation token tests to use the new style renewers</b><br>
+ <blockquote>Currently, TestDelegationTokenRenewal and TestDelegationTokenFetcher use the old style renewal and fail.<br><br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7645">HADOOP-7645</a>.
+ Blocker bug reported by atm and fixed by jnp (security)<br>
+ <b>HTTP auth tests requiring Kerberos infrastructure are not disabled on branch-0.20-security</b><br>
+ <blockquote>The back-port of HADOOP-7119 to branch-0.20-security included tests which require Kerberos infrastructure in order to run. In trunk and 0.23, these are disabled unless one enables the {{testKerberos}} maven profile. In branch-0.20-security, these tests are always run regardless, and so fail most of the time.<br><br>See this Jenkins build for an example: https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-0.20-security/26/</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7649">HADOOP-7649</a>.
+ Blocker bug reported by kihwal and fixed by jnp (security, test)<br>
+ <b>TestMapredGroupMappingServiceRefresh and TestRefreshUserMappings fail after HADOOP-7625</b><br>
+ <blockquote>TestMapredGroupMappingServiceRefresh and TestRefreshUserMappings fail after HADOOP-7625.<br>The classpath has been changed, so they try to create the rsrc file in a jar and fail.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7655">HADOOP-7655</a>.
+ Major improvement reported by arpitgupta and fixed by arpitgupta <br>
+ <b>provide a small validation script that smoke tests the installed cluster</b><br>
+ <blockquote>currently we have scripts that will setup a hadoop cluster, create users etc. We should add a script that will smoke test the installed cluster. The script could run 3 small mr jobs teragen, terasort and teravalidate and cleanup once its done.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7658">HADOOP-7658</a>.
+ Major bug reported by gkesavan and fixed by eyang <br>
+ <b>to fix hadoop config template</b><br>
+ <blockquote>hadoop rpm config template by default sets the HADOOP_SECURE_DN_USER, HADOOP_SECURE_DN_LOG_DIR & HADOOP_SECURE_DN_PID_DIR <br>the above values should only be set for secured deployment ; <br># On secure datanodes, user to run the datanode as after dropping privileges<br>export HADOOP_SECURE_DN_USER=${HADOOP_HDFS_USER}<br><br># Where log files are stored. $HADOOP_HOME/logs by default.<br>export HADOOP_LOG_DIR=${HADOOP_LOG_DIR}/$USER<br><br># Where log files are stored in the secure data environment.<br>export HADOOP_SE...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7661">HADOOP-7661</a>.
+ Major bug reported by jnp and fixed by jnp <br>
+ <b>FileSystem.getCanonicalServiceName throws NPE for any file system uri that doesn't have an authority.</b><br>
+ <blockquote>FileSystem.getCanonicalServiceName throws NPE for any file system uri that doesn't have an authority. <br><br>....<br>java.lang.NullPointerException<br>at org.apache.hadoop.net.NetUtils.createSocketAddr(NetUtils.java:138)<br>at org.apache.hadoop.security.SecurityUtil.buildDTServiceName(SecurityUtil.java:261)<br>at org.apache.hadoop.fs.FileSystem.getCanonicalServiceName(FileSystem.java:174)<br>....</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7674">HADOOP-7674</a>.
+ Major bug reported by jnp and fixed by jnp <br>
+ <b>TestKerberosName fails in 20 branch.</b><br>
+ <blockquote>TestKerberosName fails in 20 branch. In fact this test has got duplicated in 20, with a little change to the rules.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7676">HADOOP-7676</a>.
+ Major bug reported by gkesavan and fixed by gkesavan <br>
+ <b>add rules to the core-site.xml template</b><br>
+ <blockquote>add rules for master and region in core-site.xml template.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7679">HADOOP-7679</a>.
+ Major bug reported by rramya and fixed by rramya (conf)<br>
+ <b>log4j.properties templates does not define mapred.jobsummary.logger</b><br>
+ <blockquote>In templates/conf/hadoop-env.sh, HADOOP_JOBTRACKER_OPTS is defined as -Dsecurity.audit.logger=INFO,DRFAS -Dmapred.audit.logger=INFO,MRAUDIT -Dmapred.jobsummary.logger=INFO,JSA ${HADOOP_JOBTRACKER_OPTS}<br>However, in templates/conf/hadoop-env.sh, instead of mapred.jobsummary.logger, hadoop.mapreduce.jobsummary.logger is defined as follows:<br>hadoop.mapreduce.jobsummary.logger=${hadoop.root.logger}<br>This is preventing collection of jobsummary logs.<br><br>We have to consistently use mapred.jobsummary.logg...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7681">HADOOP-7681</a>.
+ Minor bug reported by arpitgupta and fixed by arpitgupta (conf)<br>
+ <b>log4j.properties is missing properties for security audit and hdfs audit should be changed to info</b><br>
+ <blockquote>(Arpit Gupta via Eric Yang)<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7683">HADOOP-7683</a>.
+ Minor bug reported by arpitgupta and fixed by arpitgupta <br>
+ <b>hdfs-site.xml template has properties that are not used in 20</b><br>
+ <blockquote>properties dfs.namenode.http-address and dfs.namenode.https-address should be removed</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7684">HADOOP-7684</a>.
+ Major bug reported by eyang and fixed by eyang (scripts)<br>
+ <b>jobhistory server and secondarynamenode should have init.d script</b><br>
+ <blockquote> Added init.d script for jobhistory server and secondary namenode. (Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7685">HADOOP-7685</a>.
+ Major bug reported by devaraj.k and fixed by eyang (scripts)<br>
+ <b>Issues with hadoop-common-project\hadoop-common\src\main\packages\hadoop-setup-conf.sh file </b><br>
+ <blockquote>hadoop-common-project\hadoop-common\src\main\packages\hadoop-setup-conf.sh has following issues<br>1. check_permission does not work as expected if there are two folders with $NAME as part of their name inside $PARENT<br>e.g. /home/hadoop/conf, /home/hadoop/someconf, <br>The result of `ls -ln $PARENT | grep -w $NAME| awk '{print $3}'` is non zero..it is 0 0 and hence the following if check becomes true.<br>{code:xml}<br>if [ "$OWNER" != "0" ]; then<br>RESULT=1<br>break<br>fi <br>{code}<br><br>2. Spelling mistake<br>{code:xml}<br>H...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7691">HADOOP-7691</a>.
+ Major bug reported by gkesavan and fixed by eyang <br>
+ <b>hadoop deb pkg should take a diff group id</b><br>
+ <blockquote> Fixed conflict uid for install packages. (Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7707">HADOOP-7707</a>.
+ Major improvement reported by arpitgupta and fixed by arpitgupta (conf)<br>
+ <b>improve config generator to allow users to specify proxy user, turn append on or off, turn webhdfs on or off</b><br>
+ <blockquote> Added toggle for dfs.support.append, webhdfs and hadoop proxy user to setup config script. (Arpit Gupta via Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7708">HADOOP-7708</a>.
+ Critical bug reported by arpitgupta and fixed by eyang (conf)<br>
+ <b>config generator does not update the properties file if on exists already</b><br>
+ <blockquote> Fixed hadoop-setup-conf.sh to handle config file consistently. (Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7710">HADOOP-7710</a>.
+ Major improvement reported by arpitgupta and fixed by arpitgupta <br>
+ <b>create a script to setup application in order to create root directories for application such hbase, hcat, hive etc</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7711">HADOOP-7711</a>.
+ Major bug reported by arpitgupta and fixed by arpitgupta (conf)<br>
+ <b>hadoop-env.sh generated from templates has duplicate info</b><br>
+ <blockquote> Fixed recursive sourcing of HADOOP_OPTS environment variables (Arpit Gupta via Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7715">HADOOP-7715</a>.
+ Major bug reported by arpitgupta and fixed by eyang (conf)<br>
+ <b>see log4j Error when running mr jobs and certain dfs calls</b><br>
+ <blockquote> Removed unnecessary security logger configuration. (Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7720">HADOOP-7720</a>.
+ Major improvement reported by arpitgupta and fixed by arpitgupta (conf)<br>
+ <b>improve the hadoop-setup-conf.sh to read in the hbase user and setup the configs</b><br>
+ <blockquote> Added parameter for HBase user to setup config script. (Arpit Gupta via Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7721">HADOOP-7721</a>.
+ Major bug reported by arpitgupta and fixed by jnp <br>
+ <b>dfs.web.authentication.kerberos.principal expects the full hostname and does not replace _HOST with the hostname</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HADOOP-7724">HADOOP-7724</a>.
+ Major bug reported by gkesavan and fixed by arpitgupta <br>
+ <b>hadoop-setup-conf.sh should put proxy user info into the core-site.xml </b><br>
+ <blockquote> Fixed hadoop-setup-conf.sh to put proxy user in core-site.xml. (Arpit Gupta via Eric Yang)<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-142">HDFS-142</a>.
+ Blocker bug reported by rangadi and fixed by dhruba <br>
+ <b>In 0.20, move blocks being written into a blocksBeingWritten directory</b><br>
+ <blockquote>Before 0.18, when Datanode restarts, it deletes files under data-dir/tmp directory since these files are not valid anymore. But in 0.18 it moves these files to normal directory incorrectly making them valid blocks. One of the following would work :<br><br>- remove the tmp files during upgrade, or<br>- if the files under /tmp are in pre-18 format (i.e. no generation), delete them.<br><br>Currently effect of this bug is that, these files end up failing block verification and eventually get deleted. But cause...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-200">HDFS-200</a>.
+ Blocker new feature reported by szetszwo and fixed by dhruba <br>
+ <b>In HDFS, sync() not yet guarantees data available to the new readers</b><br>
+ <blockquote>In the append design doc (https://issues.apache.org/jira/secure/attachment/12370562/Appends.doc), it says<br>* A reader is guaranteed to be able to read data that was 'flushed' before the reader opened the file<br><br>However, this feature is not yet implemented. Note that the operation 'flushed' is now called "sync".</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-561">HDFS-561</a>.
+ Major sub-task reported by kzhang and fixed by kzhang (data-node, hdfs client)<br>
+ <b>Fix write pipeline READ_TIMEOUT</b><br>
+ <blockquote>When writing a file, the pipeline status read timeouts for datanodes are not set up properly.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-606">HDFS-606</a>.
+ Major bug reported by shv and fixed by shv (name-node)<br>
+ <b>ConcurrentModificationException in invalidateCorruptReplicas()</b><br>
+ <blockquote>{{BlockManager.invalidateCorruptReplicas()}} iterates over DatanodeDescriptor-s while removing corrupt replicas from the descriptors. This causes {{ConcurrentModificationException}} if there is more than one replicas of the block. I ran into this exception debugging different scenarios in append, but it should be fixed in the trunk too.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-630">HDFS-630</a>.
+ Major improvement reported by mry.maillist and fixed by clehene (hdfs client, name-node)<br>
+ <b>In DFSOutputStream.nextBlockOutputStream(), the client can exclude specific datanodes when locating the next block.</b><br>
+ <blockquote>created from hdfs-200.<br><br>If during a write, the dfsclient sees that a block replica location for a newly allocated block is not-connectable, it re-requests the NN to get a fresh set of replica locations of the block. It tries this dfs.client.block.write.retries times (default 3), sleeping 6 seconds between each retry ( see DFSClient.nextBlockOutputStream).<br><br>This setting works well when you have a reasonable size cluster; if u have few datanodes in the cluster, every retry maybe pick the dead-d...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-724">HDFS-724</a>.
+ Blocker bug reported by szetszwo and fixed by hairong (data-node, hdfs client)<br>
+ <b>Pipeline close hangs if one of the datanode is not responsive.</b><br>
+ <blockquote>In the new pipeline design, pipeline close is implemented by sending an additional empty packet. If one of the datanode does not response to this empty packet, the pipeline hangs. It seems that there is no timeout.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-826">HDFS-826</a>.
+ Major improvement reported by dhruba and fixed by dhruba (hdfs client)<br>
+ <b>Allow a mechanism for an application to detect that datanode(s) have died in the write pipeline</b><br>
+ <blockquote>HDFS does not replicate the last block of the file that is being currently written to by an application. Every datanode death in the write pipeline decreases the reliability of the last block of the currently-being-written block. This situation can be improved if the application can be notified of a datanode death in the write pipeline. Then, the application can decide what is the right course of action to be taken on this event.<br><br>In our use-case, the application can close the file on the fir...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-895">HDFS-895</a>.
+ Major improvement reported by dhruba and fixed by tlipcon (hdfs client)<br>
+ <b>Allow hflush/sync to occur in parallel with new writes to the file</b><br>
+ <blockquote>In the current trunk, the HDFS client methods writeChunk() and hflush./sync are syncronized. This means that if a hflush/sync is in progress, an applicationn cannot write data to the HDFS client buffer. This reduces the write throughput of the transaction log in HBase. <br><br>The hflush/sync should allow new writes to happen to the HDFS client even when a hflush/sync is in progress. It can record the seqno of the message for which it should receice the ack, indicate to the DataStream thread to sta...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-988">HDFS-988</a>.
+ Blocker bug reported by dhruba and fixed by eli (name-node)<br>
+ <b>saveNamespace race can corrupt the edits log</b><br>
+ <blockquote>The adminstrator puts the namenode is safemode and then issues the savenamespace command. This can corrupt the edits log. The problem is that when the NN enters safemode, there could still be pending logSycs occuring from other threads. Now, the saveNamespace command, when executed, would save a edits log with partial writes. I have seen this happen on 0.20.<br><br>https://issues.apache.org/jira/browse/HDFS-909?focusedCommentId=12828853&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1054">HDFS-1054</a>.
+ Major improvement reported by tlipcon and fixed by tlipcon (hdfs client)<br>
+ <b>Remove unnecessary sleep after failure in nextBlockOutputStream</b><br>
+ <blockquote>If DFSOutputStream fails to create a pipeline, it currently sleeps 6 seconds before retrying. I don't see a great reason to wait at all, much less 6 seconds (especially now that HDFS-630 ensures that a retry won't go back to the bad node). We should at least make it configurable, and perhaps something like backoff makes some sense.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1057">HDFS-1057</a>.
+ Blocker sub-task reported by tlipcon and fixed by rash37 (data-node)<br>
+ <b>Concurrent readers hit ChecksumExceptions if following a writer to very end of file</b><br>
+ <blockquote>In BlockReceiver.receivePacket, it calls replicaInfo.setBytesOnDisk before calling flush(). Therefore, if there is a concurrent reader, it's possible to race here - the reader will see the new length while those bytes are still in the buffers of BlockReceiver. Thus the client will potentially see checksum errors or EOFs. Additionally, the last checksum chunk of the file is made accessible to readers even though it is not stable.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1118">HDFS-1118</a>.
+ Major bug reported by zshao and fixed by zshao <br>
+ <b>DFSOutputStream socket leak when cannot connect to DataNode</b><br>
+ <blockquote>The offending code is in {{DFSOutputStream.nextBlockOutputStream}}<br><br>This function retries several times to call {{createBlockOutputStream}}. Each time when it fails, it leaves a {{Socket}} object in {{DFSOutputStream.s}}.<br>That object is never closed, but overwritten the next time {{createBlockOutputStream}} is called.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1122">HDFS-1122</a>.
+ Major sub-task reported by rash37 and fixed by rash37 <br>
+ <b>client block verification may result in blocks in DataBlockScanner prematurely</b><br>
+ <blockquote>found that when the DN uses client verification of a block that is open for writing, it will add it to the DataBlockScanner prematurely. </blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1141">HDFS-1141</a>.
+ Blocker bug reported by tlipcon and fixed by tlipcon (name-node)<br>
+ <b>completeFile does not check lease ownership</b><br>
+ <blockquote>completeFile should check that the caller still owns the lease of the file that it's completing. This is for the 'testCompleteOtherLeaseHoldersFile' case in HDFS-1139.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1164">HDFS-1164</a>.
+ Major bug reported by eli and fixed by tlipcon (contrib/hdfsproxy)<br>
+ <b>TestHdfsProxy is failing</b><br>
+ <blockquote>TestHdfsProxy is failing on trunk, seen in HDFS-1132 and HDFS-1143. It doesn't look like hudson posts test results for contrib and it's hard to see what's going on from the raw console output. Can someone with access to hudson upload the individual test output for TestHdfsProxy so we can see what the issue is?</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1186">HDFS-1186</a>.
+ Blocker bug reported by tlipcon and fixed by tlipcon (data-node)<br>
+ <b>0.20: DNs should interrupt writers at start of recovery</b><br>
+ <blockquote>When block recovery starts (eg due to NN recovering lease) it needs to interrupt any writers currently writing to those blocks. Otherwise, an old writer (who hasn't realized he lost his lease) can continue to write+sync to the blocks, and thus recovery ends up truncating data that has been sync()ed.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1197">HDFS-1197</a>.
+ Major bug reported by tlipcon and fixed by (data-node, hdfs client, name-node)<br>
+ <b>Blocks are considered "complete" prematurely after commitBlockSynchronization or DN restart</b><br>
+ <blockquote>I saw this failure once on my internal Hudson job that runs the append tests 48 times a day:<br>junit.framework.AssertionFailedError: expected:<114688> but was:<98304><br> at org.apache.hadoop.hdfs.AppendTestUtil.check(AppendTestUtil.java:112)<br> at org.apache.hadoop.hdfs.TestFileAppend3.testTC2(TestFileAppend3.java:116)<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1202">HDFS-1202</a>.
+ Major bug reported by tlipcon and fixed by tlipcon (data-node)<br>
+ <b>DataBlockScanner throws NPE when updated before initialized</b><br>
+ <blockquote>Missing an isInitialized() check in updateScanStatusInternal</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1204">HDFS-1204</a>.
+ Major bug reported by tlipcon and fixed by rash37 <br>
+ <b>0.20: Lease expiration should recover single files, not entire lease holder</b><br>
+ <blockquote>This was brought up in HDFS-200 but didn't make it into the branch on Apache.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1207">HDFS-1207</a>.
+ Major bug reported by tlipcon and fixed by tlipcon (name-node)<br>
+ <b>0.20-append: stallReplicationWork should be volatile</b><br>
+ <blockquote>the stallReplicationWork member in FSNamesystem is accessed by multiple threads without synchronization, but isn't marked volatile. I believe this is responsible for about 1% failure rate on TestFileAppend4.testAppendSyncChecksum* on my 8-core test boxes (looking at logs I see replication happening even though we've supposedly disabled it)</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1210">HDFS-1210</a>.
+ Trivial improvement reported by tlipcon and fixed by tlipcon (hdfs client)<br>
+ <b>DFSClient should log exception when block recovery fails</b><br>
+ <blockquote>Right now we just retry without necessarily showing the exception. It can be useful to see what the error was that prevented the recovery RPC from succeeding.<br>(I believe this only applies in 0.20 style of block recovery)</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1211">HDFS-1211</a>.
+ Minor improvement reported by tlipcon and fixed by tlipcon (data-node)<br>
+ <b>0.20 append: Block receiver should not log "rewind" packets at INFO level</b><br>
+ <blockquote>In the 0.20 append implementation, it logs an INFO level message for every packet that "rewinds" the end of the block file. This is really noisy for applications like HBase which sync every edit.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1218">HDFS-1218</a>.
+ Critical bug reported by tlipcon and fixed by tlipcon (data-node)<br>
+ <b>20 append: Blocks recovered on startup should be treated with lower priority during block synchronization</b><br>
+ <blockquote>When a datanode experiences power loss, it can come back up with truncated replicas (due to local FS journal replay). Those replicas should not be allowed to truncate the block during block synchronization if there are other replicas from DNs that have _not_ restarted.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1242">HDFS-1242</a>.
+ Major test reported by tlipcon and fixed by tlipcon <br>
+ <b>0.20 append: Add test for appendFile() race solved in HDFS-142</b><br>
+ <blockquote>This is a unit test that didn't make it into branch-0.20-append, but worth having in TestFileAppend4.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1252">HDFS-1252</a>.
+ Major test reported by tlipcon and fixed by tlipcon (test)<br>
+ <b>TestDFSConcurrentFileOperations broken in 0.20-appendj</b><br>
+ <blockquote>This test currently has several flaws:<br> - It calls DN.updateBlock with a BlockInfo instance, which then causes java.lang.RuntimeException: java.lang.NoSuchMethodException: org.apache.hadoop.hdfs.server.namenode.BlocksMap$BlockInfo.<init>() in the logs when the DN tries to send blockReceived for the block<br> - It assumes that getBlockLocations returns an up-to-date length block after a sync, which is false. It happens to work because it calls getBlockLocations directly on the NN, and thus gets a...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1260">HDFS-1260</a>.
+ Critical bug reported by tlipcon and fixed by tlipcon <br>
+ <b>0.20: Block lost when multiple DNs trying to recover it to different genstamps</b><br>
+ <blockquote>Saw this issue on a cluster where some ops people were doing network changes without shutting down DNs first. So, recovery ended up getting started at multiple different DNs at the same time, and some race condition occurred that caused a block to get permanently stuck in recovery mode. What seems to have happened is the following:<br>- FSDataset.tryUpdateBlock called with old genstamp 7091, new genstamp 7094, while the block in the volumeMap (and on filesystem) was genstamp 7093<br>- we find the b...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1346">HDFS-1346</a>.
+ Major bug reported by hairong and fixed by hairong (data-node, hdfs client)<br>
+ <b>DFSClient receives out of order packet ack</b><br>
+ <blockquote>When running 0.20 patched with HDFS-101, we sometimes see an error as follow:<br>WARN hdfs.DFSClient: DFSOutputStream ResponseProcessor exception for block blk_-2871223654872350746_21421120java.io.IOException: Responseprocessor: Expecting seq<br>no for block blk_-2871223654872350746_21421120 10280 but received 10281<br>at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$ResponseProcessor.run(DFSClient.java:2570)<br><br>This indicates that DFS client expects an ack for packet N, but receives an ack for packe...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1520">HDFS-1520</a>.
+ Major new feature reported by hairong and fixed by hairong (name-node)<br>
+ <b>HDFS 20 append: Lightweight NameNode operation to trigger lease recovery</b><br>
+ <blockquote>Currently HBase uses append to trigger the close of HLog during Hlog split. Append is a very expensive operation, which involves not only NameNode operations but creating a writing pipeline. If one of datanodes on the pipeline has a problem, this recovery may takes minutes. I'd like implement a lightweight NameNode operation to trigger lease recovery and make HBase to use this instead.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1554">HDFS-1554</a>.
+ Major improvement reported by hairong and fixed by hairong <br>
+ <b>Append 0.20: New semantics for recoverLease</b><br>
+ <blockquote> Change recoverLease API to return if the file is closed or not. It also change the semantics of recoverLease to start lease recovery immediately.<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1555">HDFS-1555</a>.
+ Major improvement reported by hairong and fixed by hairong <br>
+ <b>HDFS 20 append: Disallow pipeline recovery if a file is already being lease recovered</b><br>
+ <blockquote>When a file is under lease recovery and the writer is still alive, the write pipeline will be killed and then the writer will start a pipeline recovery. Sometimes the pipeline recovery may race before the lease recovery and as a result fail the lease recovery. This is very bad if we want to support the strong recoverLease semantics in HDFS-1554. So it would be nice if we could disallow a file's pipeline recovery while its lease recovery is in progress.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1779">HDFS-1779</a>.
+ Major bug reported by umamaheswararao and fixed by umamaheswararao (data-node, name-node)<br>
+ <b>After NameNode restart , Clients can not read partial files even after client invokes Sync.</b><br>
+ <blockquote>In Append HDFS-200 issue,<br>If file has 10 blocks and after writing 5 blocks if client invokes sync method then NN will persist the blocks information in edits. <br>After this if we restart the NN, All the DataNodes will reregister with NN. But DataNodes are not sending the blocks being written information to NN. DNs are sending the blocksBeingWritten information in DN startup. So, here NameNode can not find that the 5 persisted blocks belongs to which datanodes. This information can build based o...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-1836">HDFS-1836</a>.
+ Major bug reported by hkdennis2k and fixed by bharathm (hdfs client)<br>
+ <b>Thousand of CLOSE_WAIT socket </b><br>
+ <blockquote>$ /usr/sbin/lsof -i TCP:50010 | grep -c CLOSE_WAIT<br>4471<br><br>It is better if everything runs normal. <br>However, from time to time there are some "DataStreamer Exception: java.net.SocketTimeoutException" and "DFSClient.processDatanodeError(2507) | Error Recovery for" can be found from log file and the number of CLOSE_WAIT socket just keep increasing<br><br>The CLOSE_WAIT handles may remain for hours and days; then "Too many open file" some day.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2053">HDFS-2053</a>.
+ Minor bug reported by miguno and fixed by miguno (name-node)<br>
+ <b>Bug in INodeDirectory#computeContentSummary warning</b><br>
+ <blockquote>*How to reproduce*<br><br>{code}<br># create test directories<br>$ hadoop fs -mkdir /hdfs-1377/A<br>$ hadoop fs -mkdir /hdfs-1377/B<br>$ hadoop fs -mkdir /hdfs-1377/C<br><br># ...add some test data (few kB or MB) to all three dirs...<br><br># set space quota for subdir C only<br>$ hadoop dfsadmin -setSpaceQuota 1g /hdfs-1377/C<br><br># the following two commands _on the parent dir_ trigger the warning<br>$ hadoop fs -dus /hdfs-1377<br>$ hadoop fs -count -q /hdfs-1377<br>{code}<br><br>Warning message in the namenode logs:<br><br>{code}<br>2011-06-09 09:42...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2117">HDFS-2117</a>.
+ Minor bug reported by eli and fixed by eli (data-node)<br>
+ <b>DiskChecker#mkdirsWithExistsAndPermissionCheck may return true even when the dir is not created</b><br>
+ <blockquote>In branch-0.20-security as part of HADOOP-6566, DiskChecker#mkdirsWithExistsAndPermissionCheck will return true even if it wasn't able to create the directory, which means instead of throwing a DiskErrorException the code will proceed to getFileStatus and throw a FNF exception. Post HADOOP-7040, which modified makeInstance to catch not just DiskErrorExceptions but IOExceptions as well, this is not an issue since now the exception is caught either way. But for future modifications we should st...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2190">HDFS-2190</a>.
+ Major bug reported by atm and fixed by atm (name-node)<br>
+ <b>NN fails to start if it encounters an empty or malformed fstime file</b><br>
+ <blockquote>On startup, the NN reads the fstime file of all the configured dfs.name.dirs to determine which one to load. However, if any of the searched directories contain an empty or malformed fstime file, the NN will fail to start. The NN should be able to just proceed with starting and ignore the directory containing the bad fstime file.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2202">HDFS-2202</a>.
+ Major new feature reported by eepayne and fixed by eepayne (balancer, data-node)<br>
+ <b>Changes to balancer bandwidth should not require datanode restart.</b><br>
+ <blockquote> New dfsadmin command added: [-setBalancerBandwidth &lt;bandwidth&gt;] where bandwidth is max network bandwidth in bytes per second that the balancer is allowed to use on each datanode during balacing.<br/><br><br>This is an incompatible change in 0.23. The versions of ClientProtocol and DatanodeProtocol are changed.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2259">HDFS-2259</a>.
+ Minor bug reported by eli and fixed by eli (data-node)<br>
+ <b>DN web-UI doesn't work with paths that contain html </b><br>
+ <blockquote>The 20-based DN web UI doesn't work with paths that contain html. The paths need to be unescaped when used to access the file and escaped when printed for navigation.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2284">HDFS-2284</a>.
+ Major sub-task reported by sanjay.radia and fixed by szetszwo <br>
+ <b>Write Http access to HDFS</b><br>
+ <blockquote>HFTP allows on read access to HDFS via HTTP. Add write HTTP access to HDFS.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2300">HDFS-2300</a>.
+ Major bug reported by jnp and fixed by jnp <br>
+ <b>TestFileAppend4 and TestMultiThreadedSync fail on 20.append and 20-security.</b><br>
+ <blockquote>TestFileAppend4 and TestMultiThreadedSync fail on the 20.append and 20-security branch.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2309">HDFS-2309</a>.
+ Major bug reported by jnp and fixed by jnp <br>
+ <b>TestRenameWhileOpen fails in branch-0.20-security</b><br>
+ <blockquote>TestRenameWhileOpen is failing in branch-0.20-security.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2317">HDFS-2317</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Read access to HDFS using HTTP REST</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2318">HDFS-2318</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Provide authentication to webhdfs using SPNEGO</b><br>
+ <blockquote> Added two new conf properties dfs.web.authentication.kerberos.principal and dfs.web.authentication.kerberos.keytab for the SPNEGO servlet filter.<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2320">HDFS-2320</a>.
+ Major bug reported by sureshms and fixed by sureshms (data-node, hdfs client, name-node)<br>
+ <b>Make merged protocol changes from 0.20-append to 0.20-security compatible with previous releases.</b><br>
+ <blockquote>0.20-append changes have been merged to 0.20-security. The merge has changes to version numbers in several protocols. This jira makes the protocol changes compatible with older release, allowing clients running older version to talk to server running 205 version and clients running 205 version talk to older servers running 203, 204.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2325">HDFS-2325</a>.
+ Blocker bug reported by charlescearl and fixed by kihwal (contrib/fuse-dfs, libhdfs)<br>
+ <b>Fuse-DFS fails to build on Hadoop 20.203.0</b><br>
+ <blockquote>In building fuse-dfs, the compile fails due to an argument mismatch between call to hdfsConnectAsUser on line 40 of src/contrib/fuse-dfs/src/fuse_connect.c and an earlier definition of hdfsConnectAsUser given in src/c++/libhdfs/hdfs.h.<br>I suggest changing hdfs.h. I made the following change in hdfs.h in my local copy:<br><br>106c106,107<br>< hdfsFS hdfsConnectAsUser(const char* host, tPort port, const char *user);<br>---<br>> // hdfsFS hdfsConnectAsUser(const char* host, tPort port, const char *us...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2328">HDFS-2328</a>.
+ Critical bug reported by daryn and fixed by owen.omalley <br>
+ <b>hftp throws NPE if security is not enabled on remote cluster</b><br>
+ <blockquote>If hftp cannot locate either a hdfs or hftp token in the ugi, it will call {{getDelegationToken}} to acquire one from the remote nn. This method may return a null {{Token}} if security is disabled(*) on the remote nn. Hftp will internally call its {{setDelegationToken}} which will throw a NPE when the token is {{null}}.<br><br>(*) Actually, if any problem happens while acquiring the token it assumes security is disabled! However, it's a pre-existing issue beyond the scope of the token renewal c...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2331">HDFS-2331</a>.
+ Major bug reported by abhijit.shingate and fixed by abhijit.shingate (hdfs client)<br>
+ <b>Hdfs compilation fails</b><br>
+ <blockquote>I am trying to perform complete build from trunk folder but the compilation fails.<br><br>*Commandline:*<br>mvn clean install <br><br>*Error Message:*<br><br>[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.<br>3.2:compile (default-compile) on project hadoop-hdfs: Compilation failure<br>[ERROR] \Hadoop\SVN\trunk\hadoop-hdfs-project\hadoop-hdfs\src\main\java\org<br>\apache\hadoop\hdfs\web\WebHdfsFileSystem.java:[209,21] type parameters of <T>T<br>cannot be determined; no unique maximal instance...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2333">HDFS-2333</a>.
+ Major bug reported by ikelly and fixed by szetszwo <br>
+ <b>HDFS-2284 introduced 2 findbugs warnings on trunk</b><br>
+ <blockquote>When HDFS-2284 was submitted it made DFSOutputStream public which triggered two SC_START_IN_CTOR findbug warnings.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2338">HDFS-2338</a>.
+ Major sub-task reported by jnp and fixed by jnp <br>
+ <b>Configuration option to enable/disable webhdfs.</b><br>
+ <blockquote> Added a conf property dfs.webhdfs.enabled for enabling/disabling webhdfs.<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2340">HDFS-2340</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Support getFileBlockLocations and getDelegationToken in webhdfs</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2342">HDFS-2342</a>.
+ Blocker bug reported by kihwal and fixed by szetszwo (build)<br>
+ <b>TestSleepJob and TestHdfsProxy broken after HDFS-2284</b><br>
+ <blockquote>After HDFS-2284, TestSleepJob and TestHdfsProxy are failing.<br>The both work in rev 1167444 and fail in rev 1167663.<br>It will be great if they can be fixed for 205.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2348">HDFS-2348</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Support getContentSummary and getFileChecksum in webhdfs</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2356">HDFS-2356</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>webhdfs: support case insensitive query parameter names</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2358">HDFS-2358</a>.
+ Major bug reported by rajsaha and fixed by daryn (name-node)<br>
+ <b>NPE when the default filesystem's uri has no authority</b><br>
+ <blockquote> Give meaningful error message instead of NPE.<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2359">HDFS-2359</a>.
+ Major bug reported by rajsaha and fixed by jeagles (data-node)<br>
+ <b>NPE found in Datanode log while Disk failed during different HDFS operation</b><br>
+ <blockquote>Scenario:<br>I have a cluster of 4 DN ,each of them have 12disks.<br><br>In hdfs-site.xml I have "dfs.datanode.failed.volumes.tolerated=3" <br><br>During the execution of distcp (hdfs->hdfs), I am failing 3 disks in one Datanode, by making Data Directory permission 000, The distcp job is successful but , I am getting some NullPointerException in Datanode log<br><br>In one thread<br>$hadoop distcp /user/$HADOOPQA_USER/data1 /user/$HADOOPQA_USER/data3<br><br>In another thread in a datanode<br>$ chmod 000 /xyz/{0,1,2}/hadoop/v...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2361">HDFS-2361</a>.
+ Critical bug reported by rajsaha and fixed by jnp (name-node)<br>
+ <b>hftp is broken</b><br>
+ <blockquote>Distcp with hftp is failing.<br><br>{noformat}<br>$hadoop distcp hftp://<NNhostname>:50070/user/hadoopqa/1316814737/newtemp 1316814737/as<br>11/09/23 21:52:33 INFO tools.DistCp: srcPaths=[hftp://<NNhostname>:50070/user/hadoopqa/1316814737/newtemp]<br>11/09/23 21:52:33 INFO tools.DistCp: destPath=1316814737/as<br>Retrieving token from: https://<NN IP>:50470/getDelegationToken<br>Retrieving token from: https://<NN IP>:50470/getDelegationToken?renewer=mapred<br>11/09/23 21:52:34 INFO security.TokenCache: Got dt for h...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2366">HDFS-2366</a>.
+ Major bug reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs throws a npe when ugi is null from getDelegationToken</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2368">HDFS-2368</a>.
+ Major bug reported by arpitgupta and fixed by szetszwo <br>
+ <b>defaults created for web keytab and principal, these properties should not have defaults</b><br>
+ <blockquote>the following defaults are set in hdfs-defaults.xml<br><br><property><br> <name>dfs.web.authentication.kerberos.principal</name><br> <value>HTTP/${dfs.web.hostname}@${kerberos.realm}</value><br> <description><br> The HTTP Kerberos principal used by Hadoop-Auth in the HTTP endpoint.<br><br> The HTTP Kerberos principal MUST start with 'HTTP/' per Kerberos<br> HTTP SPENGO specification.<br> </description><br></property><br><br><property><br> <name>dfs.web.authentication.kerberos.keytab</name><br> <value>${user.home}/dfs.web....</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2373">HDFS-2373</a>.
+ Major bug reported by arpitgupta and fixed by arpitgupta <br>
+ <b>Commands using webhdfs and hftp print unnecessary debug information on the console with security enabled</b><br>
+ <blockquote>run an hdfs command using either hftp or webhdfs and it prints the following line to the console (system out)<br><br>Retrieving token from: https://NN_HOST:50470/getDelegationToken<br><br><br>Probably in the code where we get the delegation token. This should be removed as people using the dfs commands to get a handle to the content such as dfs -cat will now get an extra line that is not part of the actual content. This should either be only in the log or not logged at all.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2375">HDFS-2375</a>.
+ Blocker bug reported by sureshms and fixed by sureshms (hdfs client)<br>
+ <b>TestFileAppend4 fails in 0.20.205 branch</b><br>
+ <blockquote>TestFileAppend4 fails due to change from HDFS-2333. The test uses reflection to get to the method DFSOutputStream#getNumCurrentReplicas(). Since HDFS-2333 patch change this method from public to private, reflection get the method fails resulting in test failures.</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2385">HDFS-2385</a>.
+ Major sub-task reported by szetszwo and fixed by szetszwo <br>
+ <b>Support delegation token renewal in webhdfs</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2392">HDFS-2392</a>.
+ Critical bug reported by rajsaha and fixed by daryn (name-node)<br>
+ <b>Dist with hftp is failing again</b><br>
+ <blockquote>$ hadoop distcp hftp://<NN Hostname>:50070/user/hadoopqa/input1/part-00000 /user/hadoopqa/out3<br>11/09/30 18:57:59 INFO tools.DistCp: srcPaths=[hftp://<NN Hostname>:50070/user/hadoopqa/input1/part-00000]<br>11/09/30 18:57:59 INFO tools.DistCp: destPath=/user/hadoopqa/out3<br>11/09/30 18:58:00 INFO security.TokenCache: Got dt for<br>hftp://<NN Hostname>:50070/user/hadoopqa/input1/part-00000;uri=<NN IP>:50470;t.service=<NN IP>:50470<br>11/09/30 18:58:00 INFO hdfs.DFSClient: Created HDFS_DELEGATION_TOKEN toke...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2395">HDFS-2395</a>.
+ Critical bug reported by arpitgupta and fixed by szetszwo <br>
+ <b>webhdfs api's should return a root element in the json response</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2403">HDFS-2403</a>.
+ Major bug reported by szetszwo and fixed by szetszwo <br>
+ <b>The renewer in NamenodeWebHdfsMethods.generateDelegationToken(..) is not used</b><br>
+ <blockquote>Below are some suggestions from Suresh.<br># renewer not used in #generateDelegationToken<br># put() does not use InputStream in and should not throw URISyntaxException<br># post() does not use InputStream in and should not throw URISyntaxException<br># get() should not throw URISyntaxException<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2404">HDFS-2404</a>.
+ Major bug reported by arpitgupta and fixed by sureshms <br>
+ <b>webhdfs liststatus json response is not correct</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2408">HDFS-2408</a>.
+ Blocker bug reported by stack and fixed by stack (hdfs client)<br>
+ <b>DFSClient#getNumCurrentReplicas is package private in 205 but public in branch-0.20-append</b><br>
+ <blockquote>The below commit broke hdfs-826 for hbase in 205 rc1. It changes the accessiblity from public to package private on getNumCurrentReplicas and now current shipping hbase's at least cannot get at this method.<br><br>{code}<br>Revision 1174483 - (view) (download) (annotate) - [select for diffs] <br>Modified Fri Sep 23 01:30:18 2011 UTC (13 days, 4 hours ago) by szetszwo <br>File length: 136876 byte(s) <br>Diff to previous 1174479 (colored)<br>svn merge -c 1171137 from branch-0.20-security for HDFS-2333.<br>{code}<br><br>Her...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/HDFS-2411">HDFS-2411</a>.
+ Major bug reported by arpitgupta and fixed by jnp <br>
+ <b>with webhdfs enabled in secure mode the auth to local mappings are not being respected.</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-1734">MAPREDUCE-1734</a>.
+ Blocker improvement reported by tomwhite and fixed by tlipcon (documentation)<br>
+ <b>Un-deprecate the old MapReduce API in the 0.20 branch</b><br>
+ <blockquote>This issue is to un-deprecate the "old" MapReduce API (in o.a.h.mapred) in the next 0.20 release, as discussed at http://www.mail-archive.com/mapreduce-dev@hadoop.apache.org/msg01833.html</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-2187">MAPREDUCE-2187</a>.
+ Major bug reported by azaroth and fixed by anupamseth <br>
+ <b>map tasks timeout during sorting</b><br>
+ <blockquote> I just committed this. Thanks Anupam!<br><br> <br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-2324">MAPREDUCE-2324</a>.
+ Major bug reported by tlipcon and fixed by revans2 <br>
+ <b>Job should fail if a reduce task can't be scheduled anywhere</b><br>
+ <blockquote>If there's a reduce task that needs more disk space than is available on any mapred.local.dir in the cluster, that task will stay pending forever. For example, we produced this in a QA cluster by accidentally running terasort with one reducer - since no mapred.local.dir had 1T free, the job remained in pending state for several days. The reason for the "stuck" task wasn't clear from a user perspective until we looked at the JT logs.<br><br>Probably better to just fail the job if a reduce task goes ...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-2489">MAPREDUCE-2489</a>.
+ Major bug reported by naisbitt and fixed by naisbitt (jobtracker)<br>
+ <b>Jobsplits with random hostnames can make the queue unusable</b><br>
+ <blockquote>We saw an issue where a custom InputSplit was returning invalid hostnames for the splits that were then causing the JobTracker to attempt to excessively resolve host names. This caused a major slowdown for the JobTracker. We should prevent invalid InputSplit hostnames from affecting everyone else.<br><br>I propose we implement some verification for the hostnames to try to ensure that we only do DNS lookups on valid hostnames (and fail otherwise). We could also fail the job after a certain number...</blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-2494">MAPREDUCE-2494</a>.
+ Major improvement reported by revans2 and fixed by revans2 (distributed-cache)<br>
+ <b>Make the distributed cache delete entires using LRU priority</b><br>
+ <blockquote> Added config option mapreduce.tasktracker.cache.local.keep.pct to the TaskTracker. It is the target percentage of the local distributed cache that should be kept in between garbage collection runs. In practice it will delete unused distributed cache entries in LRU order until the size of the cache is less than mapreduce.tasktracker.cache.local.keep.pct of the maximum cache size. This is a floating point value between 0.0 and 1.0. The default is 0.95.<br></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-2549">MAPREDUCE-2549</a>.
+ Major bug reported by devaraj.k and fixed by devaraj.k (contrib/eclipse-plugin, contrib/streaming)<br>
+ <b>Potential resource leaks in HadoopServer.java, RunOnHadoopWizard.java and Environment.java</b><br>
+ <blockquote></blockquote></li>
+
+<li> <a href="https://issues.apache.org/jira/browse/MAPREDUCE-2610">MAPREDUCE-2610</a>.
+ Major bug reported by jrottinghuis and fixed by jrottinghuis (client)<br>
+ <b>Inconsistent API JobClient.getQueueAclsForCurrentUser</b><br>
[... 2039 lines stripped ...]