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

Sergey Shelukhin commented on HBASE-7268:
-----------------------------------------

No, in case of a server it's server timestamp (e.g. LATEST_TIMESTAMP), as 
there's nothing from master. Given that split happens locally I wonder of 
original region TS can be used, this will be later than any other change from 
master for that region but earlier than any change for daughters.
Overall though I wonder what you think about this patch (the way it works is 
supplying master timestamp thru open and close region requests to the server 
and saving them into Meta after that)... it seems like sort of an overkill for 
me and I don't feel good about mucking with meta timestamps.
                
> correct local region location cache information can be overwritten w/stale 
> information from an old server
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-7268
>                 URL: https://issues.apache.org/jira/browse/HBASE-7268
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.96.0
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>            Priority: Minor
>             Fix For: 0.96.0
>
>         Attachments: HBASE-7268-v0.patch, HBASE-7268-v0.patch, 
> HBASE-7268-v1.patch, HBASE-7268-v2.patch, HBASE-7268-v2-plus-masterTs.patch, 
> HBASE-7268-v2-plus-masterTs.patch
>
>
> Discovered via HBASE-7250; related to HBASE-5877.
> Test is writing from multiple threads.
> Server A has region R; client knows that.
> R gets moved from A to server B.
> B gets killed.
> R gets moved by master to server C.
> ~15 seconds later, client tries to write to it (on A?).
> Multiple client threads report from RegionMoved exception processing logic "R 
> moved from C to B", even though such transition never happened (neither in 
> nor before the sequence described below). Not quite sure how the client 
> learned of the transition to C, I assume it's from meta from some other 
> thread...
> Then, put fails (it may fail due to accumulated errors that are not logged, 
> which I am investigating... but the bogus cache update is there 
> nonwithstanding).
> I have a patch but not sure if it works, test still fails locally for yet 
> unknown reason.

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