[
https://issues.apache.org/jira/browse/HBASE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-9732:
---------------------------------
Attachment: 9732-trunk.txt
And the trunk version.
Note that seekCount in StoreFileScanner is no longer final, and it is also not
declared as volatile (as that would again imply read/write barrier just to
check whether the reference is null).
It is up to the (single) test to do the right thing.
I cannot stress enough how bad this is. All StoreFileScanners running inside a
RegionServer content for this one AtomicLong on each seeks just for this this
test. Running 3 client that all filter all rows with a RowFilter (which does a
seek to the next row) gives a 10% improvement with this simple patch.
> Static AtomicLong updated in StoreFileScanner every (re)seek
> ------------------------------------------------------------
>
> Key: HBASE-9732
> URL: https://issues.apache.org/jira/browse/HBASE-9732
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Fix For: 0.98.0, 0.94.13, 0.96.1
>
> Attachments: 9732-0.94.txt, 9732-trunk.txt
>
>
> To verify a single test case, we update a static AtomicLong for *every* seek
> performed on a RegionServer. This is especially bad with multiple seeks going
> on at the same time.
> W.T.F...?
> This penalty should only be incured when we're actually testing and need to
> count the seeks.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
