Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-525

ListPathsServlet.java uses static SimpleDateFormat that has threading issues

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.20.1, 0.21.0
    • Component/s: namenode
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      SimpleDateFormat is not thread safe. Multiple threads accessing the servlet can cause threading issues

      1. HDFS-525.rel20.patch
        10 kB
        Suresh Srinivas
      2. HDFS-525.patch
        8 kB
        Suresh Srinivas
      3. HDFS-525.patch
        8 kB
        Suresh Srinivas
      4. HDFS-525.2.patch
        10 kB
        Suresh Srinivas
      5. HDFS-525.1.patch
        11 kB
        Suresh Srinivas
      6. HDFS.525-3v20.patch
        5 kB
        Chris Douglas
      7. HDFS.525-3.patch
        5 kB
        Chris Douglas
      8. HDFS.525-3.patch
        5 kB
        Chris Douglas

        Activity

        Hide
        Suresh Srinivas added a comment -

        Additionally the following code masks any exceptions issues in ListPathsServlet.doGet() try block if in finally block doc.endDocument() encounters exception.

        Show
        Suresh Srinivas added a comment - Additionally the following code masks any exceptions issues in ListPathsServlet.doGet() try block if in finally block doc.endDocument() encounters exception.
        Hide
        Koji Noguchi added a comment -

        We found this when our hftp access to the namenode started consistently failing.

        dfsclient kept on showing

        Server returned HTTP response code: 500 for URL:http://...
        

        Namenode log showing

        2009-08-03 22:20:54,411 WARN /: /listPaths/user?ugi=knoguchi,users:
        java.lang.IllegalStateException: getState() == BEFORE_XML_DECLARATION
                at org.znerd.xmlenc.XMLOutputter.endDocument(Unknown Source)
                at org.apache.hadoop.dfs.ListPathsServlet.doGet(ListPathsServlet.java:163)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
                at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
                at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:475)
                at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
                at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
                at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635)
                at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
                at org.mortbay.http.HttpServer.service(HttpServer.java:954)
                at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
                at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
                at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
                at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
                at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
                at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
        

        The very first error message on the log was different which led to this Jira.

        2009-07-30 03:04:41,582 WARN /:
        /listPaths/____?ugi=____,users: 
        java.lang.ArrayIndexOutOfBoundsException: 15
                at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
                at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2081)
                at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1996)
                at java.util.Calendar.setTimeInMillis(Calendar.java:1109)
                at java.util.Calendar.setTime(Calendar.java:1075)
                at java.text.SimpleDateFormat.format(SimpleDateFormat.java:876)
                at java.text.SimpleDateFormat.format(SimpleDateFormat.java:869)
                at java.text.DateFormat.format(DateFormat.java:316)
                at org.apache.hadoop.dfs.ListPathsServlet.writeInfo(ListPathsServlet.java:59)
                at org.apache.hadoop.dfs.ListPathsServlet.doGet(ListPathsServlet.java:154)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
                at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
                at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:475)
                at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
                at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
                at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635)
                at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
                at org.mortbay.http.HttpServer.service(HttpServer.java:954)
                at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
                at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
                at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
                at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
                at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
                at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
        
        Show
        Koji Noguchi added a comment - We found this when our hftp access to the namenode started consistently failing. dfsclient kept on showing Server returned HTTP response code: 500 for URL:http://... Namenode log showing 2009-08-03 22:20:54,411 WARN /: /listPaths/user?ugi=knoguchi,users: java.lang.IllegalStateException: getState() == BEFORE_XML_DECLARATION at org.znerd.xmlenc.XMLOutputter.endDocument(Unknown Source) at org.apache.hadoop.dfs.ListPathsServlet.doGet(ListPathsServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:475) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:814) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) The very first error message on the log was different which led to this Jira. 2009-07-30 03:04:41,582 WARN /: /listPaths/____?ugi=____,users: java.lang.ArrayIndexOutOfBoundsException: 15 at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436) at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2081) at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1996) at java.util.Calendar.setTimeInMillis(Calendar.java:1109) at java.util.Calendar.setTime(Calendar.java:1075) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:876) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:869) at java.text.DateFormat.format(DateFormat.java:316) at org.apache.hadoop.dfs.ListPathsServlet.writeInfo(ListPathsServlet.java:59) at org.apache.hadoop.dfs.ListPathsServlet.doGet(ListPathsServlet.java:154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:475) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:814) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
        Hide
        Suresh Srinivas added a comment -

        Some bugs talking about the issues related to calling unsynchronized SimpleDateFormat heavily: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6295722

        We did see this exception after which the ListPathServlet stopped working.

        Show
        Suresh Srinivas added a comment - Some bugs talking about the issues related to calling unsynchronized SimpleDateFormat heavily: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6295722 We did see this exception after which the ListPathServlet stopped working.
        Hide
        Suresh Srinivas added a comment -

        Patch uploaded to address the following multi threading issues:

        1. SimpleDateFormat.format() throws an exception ArrayIndexOfBounds on multiple threaded access.
        2. SimpleDateFormat.parse() throws parse exception or returns invalid parsed date

        Both these issues are addressed by using a ThreadLocal variable. The attached unit tests first duplicate this issue for the SimpleDateFormat. It then ensures that the ThreadLocal implemenation does not have this issue.

        Additionally, an exception in any of the followings lines in ListPathsServlet.doGet() is masked.

              final Map<String, String> root = buildRoot(request, doc);
              final String path = root.get("path");
              final boolean recur = "yes".equals(root.get("recursive"));
              final Pattern filter = Pattern.compile(root.get("filter"));
              final Pattern exclude = Pattern.compile(root.get("exclude"));
              ClientProtocol nnproxy = createNameNodeProxy(ugi);
        

        The doc.endDocument in finally block encounters an exception and masks previous exception. This patch catches and prints the exception before proceeding to finally block.

        Show
        Suresh Srinivas added a comment - Patch uploaded to address the following multi threading issues: SimpleDateFormat.format() throws an exception ArrayIndexOfBounds on multiple threaded access. SimpleDateFormat.parse() throws parse exception or returns invalid parsed date Both these issues are addressed by using a ThreadLocal variable. The attached unit tests first duplicate this issue for the SimpleDateFormat. It then ensures that the ThreadLocal implemenation does not have this issue. Additionally, an exception in any of the followings lines in ListPathsServlet.doGet() is masked. final Map<String, String> root = buildRoot(request, doc); final String path = root.get("path"); final boolean recur = "yes".equals(root.get("recursive")); final Pattern filter = Pattern.compile(root.get("filter")); final Pattern exclude = Pattern.compile(root.get("exclude")); ClientProtocol nnproxy = createNameNodeProxy(ugi); The doc.endDocument in finally block encounters an exception and masks previous exception. This patch catches and prints the exception before proceeding to finally block.
        Hide
        Suresh Srinivas added a comment -

        I will open another jira to move the the thread safe implementation of SimpleDateFormat to util package. This jira will also review the non thread safe static SimpleDateFormat usage in HDFS and map/reduce code.

        Show
        Suresh Srinivas added a comment - I will open another jira to move the the thread safe implementation of SimpleDateFormat to util package. This jira will also review the non thread safe static SimpleDateFormat usage in HDFS and map/reduce code.
        Hide
        Koji Noguchi added a comment -

        Suresh, should we re-throw the exception after catching the exception and logging it?

        Show
        Koji Noguchi added a comment - Suresh, should we re-throw the exception after catching the exception and logging it?
        Hide
        Suresh Srinivas added a comment -

        Koji, thanks for the comments. I have modified the code to throw the exceptions caught (there is not need to catch it). Also doc.endDocument() call is moved to try block. This prevents it masking an earlier exception.

        Show
        Suresh Srinivas added a comment - Koji, thanks for the comments. I have modified the code to throw the exceptions caught (there is not need to catch it). Also doc.endDocument() call is moved to try block. This prevents it masking an earlier exception.
        Hide
        Tsz Wo Nicholas Sze added a comment -

        > I will open another jira to move the the thread safe implementation of SimpleDateFormat to util package.
        Why not put the new class in org.apache.hadoop.hdfs.server.common.Util in this issue?

        Public API need javadoc, otherwise, QA probably will -1.

        Show
        Tsz Wo Nicholas Sze added a comment - > I will open another jira to move the the thread safe implementation of SimpleDateFormat to util package. Why not put the new class in org.apache.hadoop.hdfs.server.common.Util in this issue? Public API need javadoc, otherwise, QA probably will -1.
        Hide
        Suresh Srinivas added a comment -

        New patch that incorporates comments from Nicholas. I have moved the ThreadLocalDateFormat class to oah.server.common package.

        Show
        Suresh Srinivas added a comment - New patch that incorporates comments from Nicholas. I have moved the ThreadLocalDateFormat class to oah.server.common package.
        Hide
        Tsz Wo Nicholas Sze added a comment -

        +1 patch looks good.

        Some thoughts:
        I appreciate the effort of adding a nice test, which is something we have to do in order to pass the QA requirement. But (1) concurrent accessing a non-thread-safe class is an obvious bug, (2) using a ThreadLocal variable is a standard solution and (3) a unit test may take seconds (up to 30 seconds in the test provided by the patch). I am not sure whether it is worthwhile to have a new unit test in this case.

        Show
        Tsz Wo Nicholas Sze added a comment - +1 patch looks good. Some thoughts: I appreciate the effort of adding a nice test, which is something we have to do in order to pass the QA requirement. But (1) concurrent accessing a non-thread-safe class is an obvious bug, (2) using a ThreadLocal variable is a standard solution and (3) a unit test may take seconds (up to 30 seconds in the test provided by the patch). I am not sure whether it is worthwhile to have a new unit test in this case.
        Hide
        gary murry added a comment -

        I think it is good to have the unit test. It does not have to be included in the 10 minutes test if we are concerned about the time.

        I do agree that we do not need the negative test case.

        Show
        gary murry added a comment - I think it is good to have the unit test. It does not have to be included in the 10 minutes test if we are concerned about the time. I do agree that we do not need the negative test case.
        Hide
        Suresh Srinivas added a comment -

        It is important to have unit test to ensure correct functionality. The only reason why I left the negative test case is to justify 30 seconds wait time for which we run multi threaded access. The first negative test that proves there is a threading issue fails in under a second. This should not add to the time of the test.

        BTW as Gary indicated, my intention was not to include this in under 10 minute tests.

        Show
        Suresh Srinivas added a comment - It is important to have unit test to ensure correct functionality. The only reason why I left the negative test case is to justify 30 seconds wait time for which we run multi threaded access. The first negative test that proves there is a threading issue fails in under a second. This should not add to the time of the test. BTW as Gary indicated, my intention was not to include this in under 10 minute tests.
        Hide
        Suresh Srinivas added a comment -

        After discussing with Gary, got rid of negative test for SimpleDateFormat and only retaining the test for ThreadLocalDateFormat.

        Show
        Suresh Srinivas added a comment - After discussing with Gary, got rid of negative test for SimpleDateFormat and only retaining the test for ThreadLocalDateFormat.
        Hide
        gary murry added a comment -

        +1 QA

        Show
        gary murry added a comment - +1 QA
        Hide
        Suresh Srinivas added a comment -

        New patch passed all the unit tests with an additional patch from HDFS-534, except the test TestHDFSTrash. Here is the test-patch result:

        [exec] +1 overall.
        [exec]
        [exec] +1 @author. The patch does not contain any @author tags.
        [exec]
        [exec] +1 tests included. The patch appears to include 3 new or modified tests.
        [exec]
        [exec] +1 javadoc. The javadoc tool did not generate any warning messages.
        [exec]
        [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings.
        [exec]
        [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings.
        [exec]
        [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings.

        Show
        Suresh Srinivas added a comment - New patch passed all the unit tests with an additional patch from HDFS-534 , except the test TestHDFSTrash . Here is the test-patch result: [exec] +1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings.
        Hide
        Tsz Wo Nicholas Sze added a comment -

        I have committed this. Thanks, Suresh!

        Show
        Tsz Wo Nicholas Sze added a comment - I have committed this. Thanks, Suresh!
        Hide
        Suresh Srinivas added a comment -

        Attaching equivalent patch for release 20. The new patch has changed tests from Junit 4 compliance to Junit 3 (for older release).

        Show
        Suresh Srinivas added a comment - Attaching equivalent patch for release 20. The new patch has changed tests from Junit 4 compliance to Junit 3 (for older release).
        Hide
        Tsz Wo Nicholas Sze added a comment -

        Reopen for committing this to 0.20.

        Show
        Tsz Wo Nicholas Sze added a comment - Reopen for committing this to 0.20.
        Hide
        Tsz Wo Nicholas Sze added a comment -

        I have also committed this to 0.20.1.

        Show
        Tsz Wo Nicholas Sze added a comment - I have also committed this to 0.20.1.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Hdfs-trunk #47 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk/47/)

        Show
        Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #47 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk/47/ )
        Hide
        Chris Douglas added a comment -

        Sorry to be late to this issue, but a wrapper class for a ThreadLocal wrapping the format is a really odd pattern. What is the virtue of this approach? Why wouldn't one simply create ThreadLocal protecting the format in contexts where multiple threads may access it?

        Show
        Chris Douglas added a comment - Sorry to be late to this issue, but a wrapper class for a ThreadLocal wrapping the format is a really odd pattern. What is the virtue of this approach? Why wouldn't one simply create ThreadLocal protecting the format in contexts where multiple threads may access it?
        Hide
        Suresh Srinivas added a comment -

        I am not sure what you mean by odd pattern. The advantage clearly is to be able to replace the existing SimpleDateFormat with ThreadLocalDateFormat, without having to add all the code related to making a thread local SimpleDateFormat in every place.

        Show
        Suresh Srinivas added a comment - I am not sure what you mean by odd pattern. The advantage clearly is to be able to replace the existing SimpleDateFormat with ThreadLocalDateFormat, without having to add all the code related to making a thread local SimpleDateFormat in every place.
        Hide
        Chris Douglas added a comment -

        ThreadLocalDateFormat and SimpleDateFormat are not related types. It's an odd pattern because the ThreadLocalDateFormat serves no purpose; it's a wrapper for a wrapper. As in the attached patch, there aren't many places where changes are required.

        Show
        Chris Douglas added a comment - ThreadLocalDateFormat and SimpleDateFormat are not related types. It's an odd pattern because the ThreadLocalDateFormat serves no purpose; it's a wrapper for a wrapper. As in the attached patch, there aren't many places where changes are required.
        Hide
        Suresh Srinivas added a comment -

        If we feel this wrapper class is not generic enough, we could go with the new patch. +1.

        Show
        Suresh Srinivas added a comment - If we feel this wrapper class is not generic enough, we could go with the new patch. +1.
        Hide
        Tsz Wo Nicholas Sze added a comment -

        > If we feel this wrapper class is not generic enough, we could go with the new patch. +1.
        How about we do it in a new issue?

        Show
        Tsz Wo Nicholas Sze added a comment - > If we feel this wrapper class is not generic enough, we could go with the new patch. +1. How about we do it in a new issue?
        Hide
        Tsz Wo Nicholas Sze added a comment -

        On a second thought, it is better to revert the patch since it was committed to both 0.20 and trunk.

        Show
        Tsz Wo Nicholas Sze added a comment - On a second thought, it is better to revert the patch since it was committed to both 0.20 and trunk.
        Hide
        Chris Douglas added a comment -

        I reverted the current, checked-in version

        Show
        Chris Douglas added a comment - I reverted the current, checked-in version
        Hide
        Chris Douglas added a comment -

        (same patch w/ --no-prefix)

             [exec] -1 overall.  
             [exec] 
             [exec]     +1 @author.  The patch does not contain any @author tags.
             [exec] 
             [exec]     -1 tests included.  The patch doesn't appear to include any new or modified tests.
             [exec]                         Please justify why no new tests are needed for this patch.
             [exec]                         Also please list what manual steps were performed to verify this patch.
             [exec] 
             [exec]     +1 javadoc.  The javadoc tool did not generate any warning messages.
             [exec] 
             [exec]     +1 javac.  The applied patch does not increase the total number of javac compiler warnings.
             [exec] 
             [exec]     +1 findbugs.  The patch does not introduce any new Findbugs warnings.
             [exec] 
             [exec]     +1 release audit.  The applied patch does not increase the total number of release audit warnings.
        

        TestDistributedFileSystem (uses HftpFileSystem) passed

        Show
        Chris Douglas added a comment - (same patch w/ --no-prefix) [exec] -1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. TestDistributedFileSystem (uses HftpFileSystem) passed
        Hide
        Chris Douglas added a comment -

        Patch for 0.20.1

        Show
        Chris Douglas added a comment - Patch for 0.20.1
        Hide
        Chris Douglas added a comment -

        I committed this

        Show
        Chris Douglas added a comment - I committed this
        Hide
        Suresh Srinivas added a comment -

        One of the other thing previous patch fixed was to move doc.endDocument() to the end of try block. This is to ensure we do not override the exception previously caused by an exception in doc.endDocument(), if doc.startTag() has not been called. That change needs to be added back to help debug the problem where servlet returns 500 response code.

        Show
        Suresh Srinivas added a comment - One of the other thing previous patch fixed was to move doc.endDocument() to the end of try block. This is to ensure we do not override the exception previously caused by an exception in doc.endDocument() , if doc.startTag() has not been called. That change needs to be added back to help debug the problem where servlet returns 500 response code.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Hdfs-trunk-Commit #5 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/5/)

        Show
        Hudson added a comment - Integrated in Hadoop-Hdfs-trunk-Commit #5 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/5/ )
        Hide
        Chris Douglas added a comment -

        Integrated the change; sorry I missed it.

        Show
        Chris Douglas added a comment - Integrated the change; sorry I missed it.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Hdfs-trunk-Commit #7 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/7/)
        . Missed a change to the exception handling

        Show
        Hudson added a comment - Integrated in Hadoop-Hdfs-trunk-Commit #7 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/7/ ) . Missed a change to the exception handling
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Hdfs-trunk #65 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk/65/)
        . Missed a change to the exception handling

        Show
        Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #65 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk/65/ ) . Missed a change to the exception handling
        Hide
        Robert Chansler added a comment -

        Editorial pass over all release notes prior to publication of 0.21.

        Show
        Robert Chansler added a comment - Editorial pass over all release notes prior to publication of 0.21.

          People

          • Assignee:
            Suresh Srinivas
            Reporter:
            Suresh Srinivas
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development