[
https://issues.apache.org/jira/browse/HBASE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334091#comment-14334091
]
Hudson commented on HBASE-12561:
--------------------------------
FAILURE: Integrated in HBase-TRUNK #6161 (See
[https://builds.apache.org/job/HBase-TRUNK/6161/])
HBASE-12561 Replicas of regions can be cached from different instances of the
table in MetaCache (enis: rev e405017a31a9253e5eecdd5cc2ba43ab182e16a0)
* hbase-client/src/test/java/org/apache/hadoop/hbase/TestRegionLocations.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RegionReplicaUtil.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/RegionReplicaReplicationEndpoint.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/RegionLocations.java
> Replicas of regions can be cached from different instances of the table in
> MetaCache
> ------------------------------------------------------------------------------------
>
> Key: HBASE-12561
> URL: https://issues.apache.org/jira/browse/HBASE-12561
> Project: HBase
> Issue Type: Sub-task
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.1.0
>
> Attachments: hbase-12561-v1.patch
>
>
> In testing, we have observed that if a client caches some regions with
> replicas in MetaCache, and then the table is recreated, the cache does not
> get invalidated. Upon caching more entries from a new instance of the table
> we can have entries for replicas from different instances of a table
> (remember that metacache is row based)
> On async wal replay (HBASE-11568), we have an elaborate mechanism to track
> region replica locations and skip replaying wal entries if the current region
> replica is not the same region replica from the original wal edit. This
> prevents replaying entries of older tables with the same name to the region
> replicas as well as replaying older entries from split (or merged) regions
> from old parent to new daughters.
> Trace level logging in my test setup showed that we were skipping some
> entries because of a case, where we would have region locations (of the same
> range) cached from different instances of the table (meaning some replicas
> are from already deleted table vs some entries from new table). This was
> causing superfluous skipping entries.
> The fix can be when we are merging entries for the same range, we simply
> check the other entries and delete those that do not match the new region id.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
