[
https://issues.apache.org/jira/browse/PHOENIX-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197474#comment-14197474
]
ramkrishna.s.vasudevan commented on PHOENIX-1402:
-------------------------------------------------
I can tell why postSplit was selected. There are multiple hooks in split code
path like pre Split hooks, pre and post hooks before and AfterPONR (the point
of no return where the region is for sure splitted atleast as per the RS) ,a
post Split hook and finally a hook to show that postCompleteSplit() which
would be called in the finally block.
Now as we are doing in the postSplit one thing we are sure is that the daughter
regions are online, they are added to META and even the notification to the
master has happened. But as we are doing this stats collection synchronously
the table lock release would be delayed. But we are not holding up the split
activitiy here.
I am sure that this would not cause NotServingRegionException.
Still collecting the stats for the splitted regions in a new thread is always
fine and I think incase of stats a failure in that thread is also not a problem
anyway as a major compaction would be triggered to collect the reference files
and rewrite them to a new file.
> Don't recalculate stats on split
> --------------------------------
>
> Key: PHOENIX-1402
> URL: https://issues.apache.org/jira/browse/PHOENIX-1402
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> Rather than scan the new regions on a split (which is potentially expensive,
> and might be causing the timeouts you're seeing [~jfernando_sfdc]), we should
> instead just split up the existing guideposts between new two new regions
> based on the split point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
