phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-1402) Don't recalculate stats on split
Date Wed, 05 Nov 2014 04:35:34 GMT


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

View raw message