[
https://issues.apache.org/jira/browse/PHOENIX-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718084#comment-14718084
]
Ravi Kishore Valeti commented on PHOENIX-2154:
----------------------------------------------
- Yes, TableRecordWriter.close gets called only after all maps are complete.
- My first take was to do a wait loop until Index state becomes active. But,
decided to go "-runfg" route because of below reasons
i) Foreground will stand as an option for user if he wants to watch the
progress online.
ii) Testing a foreground execution is equivalent of testing background job.
We do not need to test the MR Job Submission phase.
iii) Tests do not need extra logic of waiting for index state to become
active.
- Yes, One thing I observed in IndexToolIT is none of the tests are actually
checking for data validity. They are only checking if index is built. Will talk
to [~tdsilva] and add that check for all tests of IndexToolIT.
> Failure of one mapper should not affect other mappers in MR index build
> -----------------------------------------------------------------------
>
> Key: PHOENIX-2154
> URL: https://issues.apache.org/jira/browse/PHOENIX-2154
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Ravi Kishore Valeti
> Attachments: IndexTool.java, PHOENIX-2154-WIP.patch,
> PHOENIX-2154-_HBase_Frontdoor_API_WIP.patch,
> PHOENIX-2154-_HBase_Frontdoor_API_v1.patch
>
>
> Once a mapper in the MR index job succeeds, it should not need to be re-done
> in the event of the failure of one of the other mappers. The initial
> population of an index is based on a snapshot in time, so new rows getting
> *after* the index build has started and/or failed do not impact it.
> Also, there's a 1:1 correspondence between index rows and table rows, so
> there's really no need to dedup. However, the index rows will have a
> different row key than the data table, so I'm not sure how the HFiles are
> split. Will they potentially overlap and is this an issue?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
