hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Douglas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-5333) The libhdfs append API is not coded correctly
Date Mon, 09 Mar 2009 19:11:50 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680235#action_12680235
] 

Chris Douglas commented on HADOOP-5333:
---------------------------------------

*sigh* Good catch on the braces.

I'm not sure I follow the locking added to getJNIEnv. Is it related to this issue? If only
one JVM should be created and shared between all threads, can that be part of init and not
lazily created? It looks like most/all paths through libhdfs require that it exist... is it
handling failures by relying on get/set, i.e. when/if the JVM dies? I'm not very familiar
with libhdfs so please correct me if I've misread this, but appropriating the lock guarding
updates to a cache of class objects to protect the creation of a singleton seems to regard
locks as desperately scarce resources. If it's difficult to do otherwise, then perhaps this
can be a separate issue...

> The libhdfs append API is not coded correctly
> ---------------------------------------------
>
>                 Key: HADOOP-5333
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5333
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: libhdfs
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>             Fix For: 0.19.2, 0.20.0, 0.21.0
>
>         Attachments: libhdfsAppend.patch, libhdfsAppend.patch
>
>
> The hdfsOpenFile() API does not handle the APPEND bit correctly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message