[
https://issues.apache.org/jira/browse/HBASE-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132733#comment-13132733
]
jirapos...@reviews.apache.org commented on HBASE-4485:
------------------------------------------------------
bq. On 2011-10-21 06:13:51, Lars Hofhansl wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java, line
645
bq. > <https://reviews.apache.org/r/2481/diff/1/?file=51676#file51676line645>
bq. >
bq. > Can these be private?
bq. > volatile because you did not want synchronous in the MemstoreScanner
constructor?
actually, I had this volatile because the kvset in the Memstore is volatile.
But, on second thought, it seems like we can get rid of that. While the kvset
and snapshot in Memstore
can be accessed from different threads (running different Memstorescanners).
The reference in the
MemstoreScanner should only be used in the Thread that is performing the scan.
Will update the diff and send it again.
bq. On 2011-10-21 06:13:51, Lars Hofhansl wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java, line
712
bq. > <https://reviews.apache.org/r/2481/diff/1/?file=51676#file51676line712>
bq. >
bq. > Cool.
bq. >
bq. > Only concern is that while the scanner exists we may need more
memory than before.
you are right.
Are we guaranteed to do a seek() only once? If so, we probably can reset
kvset/snapshot to null,
once we have evaluated kvTail and snapshotTail.
bq. On 2011-10-21 06:13:51, Lars Hofhansl wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/Store.java, line 1335
bq. > <https://reviews.apache.org/r/2481/diff/1/?file=51677#file51677line1335>
bq. >
bq. > Why can you move this up?
Here is my understanding/assumption:
https://issues.apache.org/jira/browse/HBASE-4485?focusedCommentId=13131844&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13131844
Let me know if that is wrong :-)
- Amitanand
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2481/#review2736
-----------------------------------------------------------
On 2011-10-20 19:13:56, Amitanand Aiyer wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2481/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-10-20 19:13:56)
bq.
bq.
bq. Review request for Ted Yu, Michael Stack, Jonathan Gray, Lars Hofhansl,
Amitanand Aiyer, Kannan Muthukkaruppan, Karthik Ranganathan, and Nicolas
Spiegelberg.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Part of the 2856 diff split into 3 parts for easier review
bq.
bq. The first part is v6 of the patch submitted to:
bq. https://reviews.apache.org/r/2224/
bq.
bq. This is the fix for HBase-4485
bq.
bq.
bq. This addresses bug hbase-4485.
bq. https://issues.apache.org/jira/browse/hbase-4485
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 7761c42
bq. src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java
f5b5c4c
bq. src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java 34263e4
bq.
bq. Diff: https://reviews.apache.org/r/2481/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. running mvn test with all 3 patches together.
bq.
bq.
bq. Thanks,
bq.
bq. Amitanand
bq.
bq.
> Eliminate window of missing Data
> --------------------------------
>
> Key: HBASE-4485
> URL: https://issues.apache.org/jira/browse/HBASE-4485
> Project: HBase
> Issue Type: Sub-task
> Reporter: Amitanand Aiyer
> Assignee: Amitanand Aiyer
> Fix For: 0.94.0
>
> Attachments: 4485-v1.diff, 4485-v2.diff, 4485-v3.diff, 4485-v4.diff,
> repro_bug-4485.diff
>
>
> After incorporating v11 of the 2856 fix, we discovered that we are still
> having some ACID violations.
> This time, however, the problem is not about including "newer" updates; but,
> about missing older updates
> that should be including.
> Here is what seems to be happening.
> There is a race condition in the StoreScanner.getScanners()
> private List<KeyValueScanner> getScanners(Scan scan,
> final NavigableSet<byte[]> columns) throws IOException {
> // First the store file scanners
> List<StoreFileScanner> sfScanners = StoreFileScanner
> .getScannersForStoreFiles(store.getStorefiles(), cacheBlocks,
> isGet, false);
> List<KeyValueScanner> scanners =
> new ArrayList<KeyValueScanner>(sfScanners.size()+1);
> // include only those scan files which pass all filters
> for (StoreFileScanner sfs : sfScanners) {
> if (sfs.shouldSeek(scan, columns)) {
> scanners.add(sfs);
> }
> }
> // Then the memstore scanners
> if (this.store.memstore.shouldSeek(scan)) {
> scanners.addAll(this.store.memstore.getScanners());
> }
> return scanners;
> }
> If for example there is a call to Store.updateStorefiles() that happens
> between
> the store.getStorefiles() and this.store.memstore.getScanners(); then
> it is possible that there was a new HFile created, that is not seen by the
> StoreScanner, and the data is not present in the Memstore.snapshot either.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
