[
https://issues.apache.org/jira/browse/HBASE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813438#comment-13813438
]
Enis Soztutar commented on HBASE-9272:
--------------------------------------
bq. The metric stuff gets obtuse pretty quickly, especially when the parallel
scanner is closed and all the threads are interrupted/canceled
Slightly related, I think pushing the metrics via Scan is broken. The scan
should be a pojo, and the metrics should be obtained from the Scanner
interface. I am doing a similar thing in HBASE-8369 where you can obtain the
metrics via scanner, not the scan.
> A parallel, unordered scanner
> -----------------------------
>
> Key: HBASE-9272
> URL: https://issues.apache.org/jira/browse/HBASE-9272
> Project: HBase
> Issue Type: New Feature
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Minor
> Fix For: 0.98.0, 0.96.1, 0.94.14
>
> Attachments: 9272-0.94-v2.txt, 9272-0.94-v3.txt, 9272-0.94-v4.txt,
> 9272-0.94.txt, 9272-trunk-v2.txt, 9272-trunk-v3.txt, 9272-trunk-v3.txt,
> 9272-trunk-v4.txt, 9272-trunk.txt, ParallelClientScanner.java,
> ParallelClientScanner.java
>
>
> The contract of ClientScanner is to return rows in sort order. That limits
> the order in which region can be scanned.
> I propose a simple ParallelScanner that does not have this requirement and
> queries regions in parallel, return whatever gets returned first.
> This is generally useful for scans that filter a lot of data on the server,
> or in cases where the client can very quickly react to the returned data.
> I have a simple prototype (doesn't do error handling right, and might be a
> bit heavy on the synchronization side - it used a BlockingQueue to hand data
> between the client using the scanner and the threads doing the scanning, it
> also could potentially starve some scanners long enugh to time out at the
> server).
> On the plus side, it's only a 130 lines of code. :)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
