[
https://issues.apache.org/jira/browse/HBASE-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855504#action_12855504
]
stack commented on HBASE-2248:
------------------------------
I'm about 50% through HBASE-2248-rr-alpha3.txt:
ReadWriteConsistencyControl is missing a license (I like thename of this class
and its nice and clean looking).
This could be final:
+ private long writeNumber;
This class doesn't have to be public:
+ public static class WriteEntry {
Can you explain the below better please?
{code}
- // The Get returns the latest value but then does not return the
- // oldest, which was never deleted, ts[1].
-
+
+ // It used to be due to the internal implementation of Get, that
+ // the Get() call would return ts[4] UNLIKE the Scan below. With
+ // the switch to using Scan for Get this is no longer the case.
get = new Get(ROW);
get.addFamily(FAMILIES[0]);
get.setMaxVersions(Integer.MAX_VALUE);
result = ht.get(get);
assertNResult(result, ROW, FAMILIES[0], QUALIFIER,
- new long [] {ts[2], ts[3], ts[4]},
- new byte[][] {VALUES[2], VALUES[3], VALUES[4]},
+ new long [] {ts[1], ts[2], ts[3]},
+ new byte[][] {VALUES[1], VALUES[2], VALUES[3]},
0, 2);
{code}
Reading it, it would seem that we should be getting ts[4] because we just added
it previous?
Why do this?
{code}
- Scan scan = new Scan();
- scan.setFilter(new RowFilter(CompareFilter.CompareOp.EQUAL,
- new BinaryComparator(Bytes.toBytes("row0"))));
+ Scan scan = new Scan(Bytes.toBytes("row0"), Bytes.toBytes("row1"));
+// scan.setFilter(new RowFilter(CompareFilter.CompareOp.EQUAL,
+// new BinaryComparator(Bytes.toBytes("row0"))));
{code}
Otherwise, patch looks great.
This patch needs to be release noted describing how it changes how Get works.
> Provide new non-copy mechanism to assure atomic reads in get and scan
> ---------------------------------------------------------------------
>
> Key: HBASE-2248
> URL: https://issues.apache.org/jira/browse/HBASE-2248
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Dave Latham
> Priority: Blocker
> Fix For: 0.20.4
>
> Attachments: HBASE-2248-demonstrate-previous-impl-bugs.patch,
> HBASE-2248-GetsAsScans3.patch, HBASE-2248-rr-alpha3.txt,
> HBASE-2248-rr-pre-durability2.txt, HBASE-2248-rr-pre-durability3.txt,
> hbase-2248.gc, HBASE-2248.patch, hbase-2248.txt, readownwrites-lost.2.patch,
> readownwrites-lost.patch, Screen shot 2010-02-23 at 10.33.38 AM.png,
> threads.txt
>
>
> HBASE-2037 introduced a new MemStoreScanner which triggers a
> ConcurrentSkipListMap.buildFromSorted clone of the memstore and snapshot when
> starting a scan.
> After upgrading to 0.20.3, we noticed a big slowdown in our use of short
> scans. Some of our data repesent a time series. The data is stored in time
> series order, MR jobs often insert/update new data at the end of the series,
> and queries usually have to pick up some or all of the series. These are
> often scans of 0-100 rows at a time. To load one page, we'll observe about
> 20 such scans being triggered concurrently, and they take 2 seconds to
> complete. Doing a thread dump of a region server shows many threads in
> ConcurrentSkipListMap.biuldFromSorted which traverses the entire map of key
> values to copy it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
