hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hou Song (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-2443) A bug in unit test: TestDFSShell.testPut()
Date Mon, 31 Oct 2011 08:30:33 GMT

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

Hou Song updated HDFS-2443:

    Attachment: HDFS-2443.patch

Change the filter "FileUtil.copyContent" to "FileUtil.copy", so that the second copy thread
can be started. Move the 5 second wait to the second copy so that the first copy in the main
thread finishes successful, and the second copy fails, which is logically correct according
to asserts around the codes. 
> A bug in unit test: TestDFSShell.testPut()
> ------------------------------------------
>                 Key: HDFS-2443
>                 URL: https://issues.apache.org/jira/browse/HDFS-2443
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: test
>    Affects Versions: 0.21.0
>            Reporter: Hou Song
>         Attachments: HDFS-2443.patch
> testPut() tries to copy a file from local to a destination "dst" in HDFS, and uses a
SecurityManager to capture this action. The new SecurityManager filters out this copy action
from all actions it receives , and starts a second thread to copy a second file to the same
destination "dst" in HDFS. The main thread sleeps 5 seconds immediately after. I think the
original purpose is that, the copy from the main thread should succeed, and the second copy
from the new thread should fail because the "dst" is being written. My guess can be confirmed
by the asserts around these codes.
> However, the filter in the new SecurityManager is not right. It tries to find "FileUtil.copyContent",
but these is no method called copyContent in FileUtil, and therefore the second thread is
never started. Although the asserts always succeed, this code is not able to find bugs in
this area.
> I also debugged it, and I can never hit the break points in the second copy thread. Even
though I changed the filter from "FileUtil.copyContent" to "FileUtil.copy" and successfully
started the second thread, the second thread succeeds before the main thread resumes, which
is the opposite of the logic.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message