[ https://issues.apache.org/jira/browse/HBASE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790012#comment-13790012 ]
stack commented on HBASE-9272: ------------------------------ Looks great. +1 Minor stuff to address on commit. nit: try/finally for this bit + List<HRegionLocation> locs = t.getRegionsInRange(scan.getStartRow(), scan.getStopRow()); + t.close(); nit: presize + Map<HRegionLocation, Queue<Scan>> tasks = new HashMap<HRegionLocation, Queue<Scan>>(); -- you know how many regions nit: + * doesn't wait until the threapool actually closes -- spelling You mean volatile here? + private transient double parallelScaling = 0; Agree it should be in HTable. I like addtion to the shell. 'Task' is too generic a name for the class and the ReaderWriter looks like a Queue but as long as these classes are kept private should be fine. MyResult is a bit hokey for a class name. Done or DoneMarker? Bit more doc on its operation (it makes sense when you take a look but not reading the class alone). > A simple 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 > Attachments: 9272-0.94.txt, 9272-0.94-v2.txt, 9272-0.94-v3.txt, > 9272-0.94-v4.txt, 9272-trunk.txt, 9272-trunk-v2.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)