[
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.
