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

stack updated HBASE-2645:
-------------------------

    Attachment: 2645_hacking.txt

Hacked up patch.  Has two different users on two different filesystems 
(different dfsclients).  Enables the hdfs logging so I can see the above is 
indeed the case.  The 'regionserver' thread hangs in sync until it gets an IOE 
'Error Recovery for block.... failed because recovery from primary datanode ... 
failed 6 times'...after 40 seconds (ugh) not the lease exception I'd expect.  
                
> HLog writer can do 1-2 sync operations after lease has been recovered for 
> split process.
> ----------------------------------------------------------------------------------------
>
>                 Key: HBASE-2645
>                 URL: https://issues.apache.org/jira/browse/HBASE-2645
>             Project: HBase
>          Issue Type: Bug
>          Components: Filters
>    Affects Versions: 0.90.4
>            Reporter: Cosmin Lehene
>            Assignee: Todd Lipcon
>            Priority: Blocker
>             Fix For: 0.96.0
>
>         Attachments: 2645_hacking.txt, 2645.txt, 2645v2.txt, 2645v3.txt, 
> hdfs_1.0_editswriter_recoverlease.txt, 
> hdfs_trunk_editswriter_recoverlease.txt, 
> org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit-output.txt, 
> org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit-output.txt
>
>
> TestHLogSplit.testLogCannotBeWrittenOnceParsed is failing. 
> This test starts a thread that writes one edit to the log, syncs and counts. 
> During this, a HLog.splitLog operation is started. splitLog recovers the log 
> lease before reading the log, so that the original regionserver could not 
> wake up and write after the split process started.  
> The test compares the number of edits reported by the split process and by 
> the writer thread. Writer thread (called zombie in the test) should report <= 
>  than the splitLog (sync() might raise after the last edit gets written and 
> the edit won't get counted by zombie thread). However it appears that the 
> zombie counts 1-2 more edits. So it looks like it can sync without a lease.
> This might be a hdfs-0.20 related issue. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to