[ 
https://issues.apache.org/jira/browse/HBASE-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468986#comment-13468986
 ] 

Devaraj Das commented on HBASE-6758:
------------------------------------

In the trunk case, I think something better can be done (and the interface 
changes can be avoided). Replication.postLogRoll could do the enqueue of the 
new path in the ReplicationSource's queue. The Replication.preLogRoll would do 
everything else (creating ZK entries, etc.) except the enqueuing of the path in 
the queue.. 

The postLogRoll is currently called before the writer is reset (to 
_nextWriter_) in FSHLog.rollWriter. I propose that it be called after the 
writer is reset. That in my opinion seems to be a more precise place for 
calling postLogRoll..

Thoughts?
                
> [replication] The replication-executor should make sure the file that it is 
> replicating is closed before declaring success on that file
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-6758
>                 URL: https://issues.apache.org/jira/browse/HBASE-6758
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Devaraj Das
>            Assignee: Devaraj Das
>            Priority: Critical
>             Fix For: 0.96.0
>
>         Attachments: 6758-1-0.92.patch, 6758-2-0.92.patch, 
> 6758-trunk-1.patch, 
> TEST-org.apache.hadoop.hbase.replication.TestReplication.xml
>
>
> I have seen cases where the replication-executor would lose data to replicate 
> since the file hasn't been closed yet. Upon closing, the new data becomes 
> visible. Before that happens the ZK node shouldn't be deleted in 
> ReplicationSourceManager.logPositionAndCleanOldLogs. Changes need to be made 
> in ReplicationSource.processEndOfFile as well (currentPath related).

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