[
https://issues.apache.org/jira/browse/HBASE-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409557#comment-13409557
]
stack commented on HBASE-6337:
------------------------------
@Lars I'm not sure why it was done originally. Prakash was probably being
cautious. As long as a region does not open before log split completes, as
Chunhui says, I think we should be fine. The code as is already overwrites
recovered.edits files with same sequence number (which could happen if first
split failed and we then rerun it before region open). Maybe there are failure
scenarios we've not yet encountered or imagined -- have you tried conjure any
new ones Chunhui? And don't we have tests for some common failures already?
-- but this approach should be fine I believe.
> [MTTR] Remove renaming tmp log file in SplitLogManager
> -------------------------------------------------------
>
> Key: HBASE-6337
> URL: https://issues.apache.org/jira/browse/HBASE-6337
> Project: HBase
> Issue Type: Bug
> Reporter: chunhui shen
> Assignee: chunhui shen
> Fix For: 0.96.0, 0.94.2
>
> Attachments: HBASE-6337v1.patch, HBASE-6337v2.patch,
> HBASE-6337v3.patch
>
>
> As HBASE-6309 mentioned, we also encounter problem of
> distributed-log-splitting take much more time than matser-local-log-splitting
> because lots of SplitLogManager 's renaming operations when finishing task.
> Could we try to remove renaming tmp log file in SplitLogManager through
> splitting log to regions' recover.edits directory directly as the same as the
> master-local-log-splitting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
