[
https://issues.apache.org/jira/browse/HBASE-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14216814#comment-14216814
]
stack commented on HBASE-12411:
-------------------------------
Something odd going on up on jenkins:
{code}
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.429 sec - in
org.apache.hadoop.hbase.regionserver.TestKeyValueScanFixture
Running org.apache.hadoop.hbase.regionserver.TestSplitTransaction
Killed
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/dev-support/test-patch.sh:
line 704: 21430 Killed $MVN clean test
-Dsurefire.rerunFailingTestsCount=2 -P runAllTests -D${PROJECT_NAME}PatchProcess
Suspicious java process found - waiting 30s to see if there are just slow to
stop
There are 1 zombie tests, they should have been killed by surefire but survived
************ BEGIN zombies jstack extract
11822: Unable to open socket file: target process not responding or HotSpot VM
not loaded
The -F option can be used when the target process is not responding
11993: Unable to open socket file: target process not responding or HotSpot VM
not loaded
The -F option can be used when the target process is not responding
************ END zombies jstack extract
{code}
> Optionally enable p-reads and private readers for compactions
> -------------------------------------------------------------
>
> Key: HBASE-12411
> URL: https://issues.apache.org/jira/browse/HBASE-12411
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: Lars Hofhansl
> Fix For: 2.0.0, 0.98.9, 0.99.2
>
> Attachments: 12411-v2.txt, 12411-v3.txt, 12411-v4.txt, 12411.txt
>
>
> In the light of HDFS-6735 we might want to consider refraining from seek +
> read completely and only perform preads.
> For example currently a compaction can lock out every other scanner over the
> file which the compaction is currently reading for compaction.
> At the very least we can introduce an option to avoid seek + read, so we can
> allow testing this in various scenarios.
> This will definitely be of great importance for projects like Phoenix which
> parallelize queries intra region (and hence readers will used concurrently by
> multiple scanner with high likelihood.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)