[
https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677118#action_12677118
]
dhruba borthakur commented on HADOOP-4379:
------------------------------------------
There is ReopenProblem.java attched to this JIRA.
@Doug: Please use ReopenProblem.java:waitForLeaseRecovery(). This method
triggers near-immediate lease recovery and can be used by any application code
to take ownership of the file. Does this work for you?
@Jim: Were u using ReopenProblem.java:waitForLeaseRecovery() and still seeing
that it takes upto an hour for the waitForLeaseRecovery() method to return
success? This can happen if the original client that was writing to the file
was alive and was in communication with the namenode. In this case, the new
append-er will not be able to recover the original lease.
> In HDFS, sync() not yet guarantees data available to the new readers
> --------------------------------------------------------------------
>
> Key: HADOOP-4379
> URL: https://issues.apache.org/jira/browse/HADOOP-4379
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Reporter: Tsz Wo (Nicholas), SZE
> Assignee: dhruba borthakur
> Priority: Blocker
> Fix For: 0.19.2, 0.20.0
>
> Attachments: 4379_20081010TC3.java, fsyncConcurrentReaders.txt,
> fsyncConcurrentReaders3.patch, fsyncConcurrentReaders4.patch,
> hypertable-namenode.log.gz, Reader.java, Reader.java, reopen_test.sh,
> ReopenProblem.java, Writer.java, Writer.java
>
>
> In the append design doc
> (https://issues.apache.org/jira/secure/attachment/12370562/Appends.doc), it
> says
> * A reader is guaranteed to be able to read data that was 'flushed' before
> the reader opened the file
> However, this feature is not yet implemented. Note that the operation
> 'flushed' is now called "sync".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
