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

stack commented on HBASE-1718:
------------------------------

+1 on patch.

Its hard to test.

Here is my supposition as to why this might be responsible for hbase-1638.

Server crashes, its logs are split.  The crashed servers regions are opened 
anew and there are logs for them to replay.

The inner loop playing the reconstruction logs is this:

{code}
     while (logReader.next(key, val)) {
        maxSeqIdInLog = Math.max(maxSeqIdInLog, key.getLogSeqNum());
        .....
        // Check this edit is for me. Also, guard against writing the special
        // METACOLUMN info such as HBASE::CACHEFLUSH entries
        if (/* commented out for now - stack via jgray key.isTransactionEntry() 
|| */
            val.matchingFamily(HLog.METAFAMILY) ||
          !Bytes.equals(key.getRegionName(), regioninfo.getRegionName()) ||
          !val.matchingFamily(family.getName())) {
          continue;
        }
        // Add anything as value as long as we use same instance each time.
        reconstructedCache.add(val);
        ....
      }
{code}

So, a value might clear the family checks and get added to the 
reconstructionCache.

We call next again.  The 'val' instance is up in reconstructionCache.  The next 
deserializes a new KV into same instance.   The deserialized value might not 
make it past family checks but its already in the reconstructionCache.

This would account for our adding a single value. 

> Reuse of KeyValue during log replay could cause the wrong data to be used
> -------------------------------------------------------------------------
>
>                 Key: HBASE-1718
>                 URL: https://issues.apache.org/jira/browse/HBASE-1718
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.20.0
>            Reporter: Jonathan Gray
>            Priority: Blocker
>             Fix For: 0.20.0
>
>         Attachments: HBASE-1718-v1.patch
>
>
> Our meta table got a row key of METAROW in it.  Hard to explain how it 
> happened, but under code inspection stack found that we are reusing the same 
> KV instance for each replayed key.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to