[jira] [Commented] (HBASE-12183) FuzzyRowFilter doesn't support reverse scans
[ https://issues.apache.org/jira/browse/HBASE-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168559#comment-14168559 ] Enis Soztutar commented on HBASE-12183: --- We were discussing this offline, and one thing that came up was the unless a filter explicitly adds support for reverse scans, it will fail, and the users will be confused. Do we have an understanding of which filters (in hbase code base) lack support for reverse scans. All is covered? Maybe we can fix the remaining if any, or at least throw an exception when tried with a reverse scan. FuzzyRowFilter doesn't support reverse scans Key: HBASE-12183 URL: https://issues.apache.org/jira/browse/HBASE-12183 Project: HBase Issue Type: Bug Components: Filters Reporter: Nick Dimiduk Assignee: Nick Dimiduk Fix For: 2.0.0, 0.98.8, 0.99.1 Attachments: 12183.patch, HBASE-12183.00-0.98.patch, HBASE-12183.00-0.99.patch, HBASE-12183.00.patch, HBASE-12183.01-0.98.patch, HBASE-12183.01-0.99.patch, HBASE-12183.01.patch Try using the FuzzyRowFilter with a reversed scanner and you'll get an RPC timeout. Looking at the code, this filter ignores the reversed flag and always move forward when calculating the value of getNextCellHint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-12236) Change namespace of HTraceConfiguration dependency in 0.98
[
https://issues.apache.org/jira/browse/HBASE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu resolved HBASE-12236.
Resolution: Won't Fix
Change namespace of HTraceConfiguration dependency in 0.98
--
Key: HBASE-12236
URL: https://issues.apache.org/jira/browse/HBASE-12236
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12236-v1.txt
As discussed in thread 'NoSuchMethodError using zipkin with hbase 0.98.5',
HBaseSpanReceiver.config() method from htrace-hbase module expects parameter
of type org.htrace.HTraceConfiguration.
However, org.apache.hadoop.hbase.trace.HBaseHTraceConfiguration in 0.98
extends org.cloudera.htrace.HTraceConfiguration , leading to the following
compilation error when building htrace-hbase against 0.98:
{code}
[ERROR]
/home/hadoop/git/htrace/htrace-hbase/src/main/java/org/htrace/impl/HBaseSpanReceiver.java:[341,12]
error: method configure in class HBaseSpanReceiver cannot be applied to
given types;
{code}
Thanks to Abhishek Kumar who reported the above issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12187) Review in source the paper Simple Testing Can Prevent Most Critical Failures
[ https://issues.apache.org/jira/browse/HBASE-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168691#comment-14168691 ] Ding Yuan commented on HBASE-12187: --- Hi Stack, I'm the author of this paper you mentioned. Thanks for your attentions. I understand that it may be more convenient to build the checks implemented by aspirator into the tools you guys already use. I am very happy to help here. Do you think it would be helpful to build these checks into FindBugs or other tools you guys use? If so, I'm happy to give it a shot. Review in source the paper Simple Testing Can Prevent Most Critical Failures -- Key: HBASE-12187 URL: https://issues.apache.org/jira/browse/HBASE-12187 Project: HBase Issue Type: Bug Reporter: stack Priority: Critical Review the helpful paper https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf It describes 'catastrophic failures', especially issues where exceptions are thrown but not properly handled. Their static analysis tool Aspirator turns up a bunch of the obvious offenders (Lets add to test-patch.sh alongside findbugs?). This issue is about going through code base making sub-issues to root out these and others (Don't we have the test described in figure #6 already? I thought we did? If we don't, need to add). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12237) HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
Ted Yu created HBASE-12237:
--
Summary: HBaseZeroCopyByteString#wrap() should not be called in
hbase-client code
Key: HBASE-12237
URL: https://issues.apache.org/jira/browse/HBASE-12237
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Critical
In RegionServerCoprocessorRpcChannel#callExecService(), there is following code:
{code}
final ClientProtos.CoprocessorServiceCall call =
ClientProtos.CoprocessorServiceCall.newBuilder()
.setRow(HBaseZeroCopyByteString.wrap(HConstants.EMPTY_BYTE_ARRAY))
{code}
Calling HBaseZeroCopyByteString#wrap() in hbase-client module causes regression
w.r.t. HBASE-8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12237) HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
[
https://issues.apache.org/jira/browse/HBASE-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-12237:
---
Attachment: 12237-v1.txt
HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
Key: HBASE-12237
URL: https://issues.apache.org/jira/browse/HBASE-12237
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Critical
Attachments: 12237-v1.txt
In RegionServerCoprocessorRpcChannel#callExecService(), there is following
code:
{code}
final ClientProtos.CoprocessorServiceCall call =
ClientProtos.CoprocessorServiceCall.newBuilder()
.setRow(HBaseZeroCopyByteString.wrap(HConstants.EMPTY_BYTE_ARRAY))
{code}
Calling HBaseZeroCopyByteString#wrap() in hbase-client module causes
regression w.r.t. HBASE-8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12237) HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
[
https://issues.apache.org/jira/browse/HBASE-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-12237:
---
Status: Patch Available (was: Open)
HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
Key: HBASE-12237
URL: https://issues.apache.org/jira/browse/HBASE-12237
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Critical
Attachments: 12237-v1.txt
In RegionServerCoprocessorRpcChannel#callExecService(), there is following
code:
{code}
final ClientProtos.CoprocessorServiceCall call =
ClientProtos.CoprocessorServiceCall.newBuilder()
.setRow(HBaseZeroCopyByteString.wrap(HConstants.EMPTY_BYTE_ARRAY))
{code}
Calling HBaseZeroCopyByteString#wrap() in hbase-client module causes
regression w.r.t. HBASE-8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12237) HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
[
https://issues.apache.org/jira/browse/HBASE-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168751#comment-14168751
]
Hadoop QA commented on HBASE-12237:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12674422/12237-v1.txt
against trunk revision .
ATTACHMENT ID: 12674422
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 4
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Javadoc warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//artifact/trunk/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/11322//console
This message is automatically generated.
HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
Key: HBASE-12237
URL: https://issues.apache.org/jira/browse/HBASE-12237
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Critical
Attachments: 12237-v1.txt
In RegionServerCoprocessorRpcChannel#callExecService(), there is following
code:
{code}
final ClientProtos.CoprocessorServiceCall call =
ClientProtos.CoprocessorServiceCall.newBuilder()
.setRow(HBaseZeroCopyByteString.wrap(HConstants.EMPTY_BYTE_ARRAY))
{code}
Calling HBaseZeroCopyByteString#wrap() in hbase-client module causes
regression w.r.t. HBASE-8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12236) Change namespace of HTraceConfiguration dependency in 0.98
[
https://issues.apache.org/jira/browse/HBASE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168782#comment-14168782
]
stack commented on HBASE-12236:
---
For those trying to follow along, why does this issue go 'wont fix'?
Change namespace of HTraceConfiguration dependency in 0.98
--
Key: HBASE-12236
URL: https://issues.apache.org/jira/browse/HBASE-12236
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12236-v1.txt
As discussed in thread 'NoSuchMethodError using zipkin with hbase 0.98.5',
HBaseSpanReceiver.config() method from htrace-hbase module expects parameter
of type org.htrace.HTraceConfiguration.
However, org.apache.hadoop.hbase.trace.HBaseHTraceConfiguration in 0.98
extends org.cloudera.htrace.HTraceConfiguration , leading to the following
compilation error when building htrace-hbase against 0.98:
{code}
[ERROR]
/home/hadoop/git/htrace/htrace-hbase/src/main/java/org/htrace/impl/HBaseSpanReceiver.java:[341,12]
error: method configure in class HBaseSpanReceiver cannot be applied to
given types;
{code}
Thanks to Abhishek Kumar who reported the above issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12237) HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
[
https://issues.apache.org/jira/browse/HBASE-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-12237:
---
Fix Version/s: 0.99.2
0.98.8
2.0.0
+1
HBaseZeroCopyByteString#wrap() should not be called in hbase-client code
Key: HBASE-12237
URL: https://issues.apache.org/jira/browse/HBASE-12237
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Critical
Fix For: 2.0.0, 0.98.8, 0.99.2
Attachments: 12237-v1.txt
In RegionServerCoprocessorRpcChannel#callExecService(), there is following
code:
{code}
final ClientProtos.CoprocessorServiceCall call =
ClientProtos.CoprocessorServiceCall.newBuilder()
.setRow(HBaseZeroCopyByteString.wrap(HConstants.EMPTY_BYTE_ARRAY))
{code}
Calling HBaseZeroCopyByteString#wrap() in hbase-client module causes
regression w.r.t. HBASE-8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-11912) Catch some bad practices at compile time with error-prone
[ https://issues.apache.org/jira/browse/HBASE-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168792#comment-14168792 ] Andrew Purtell commented on HBASE-11912: Cases like HBASE-12237 could be caught with simple checks Catch some bad practices at compile time with error-prone - Key: HBASE-11912 URL: https://issues.apache.org/jira/browse/HBASE-11912 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Attachments: HBASE-11912.patch, HBASE-11912.patch Google's error-prone (https://code.google.com/p/error-prone/) wraps javac with some additional static analysis that will generate additional warnings or errors at compile time if certain bug patterns (https://code.google.com/p/error-prone/wiki/BugPatterns) are detected. What's nice about this approach, as opposed to findbugs, is the compile time detection and erroring out prevent the detected problems from getting into the codebase up front. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11912) Catch some bad practices at compile time with error-prone
[ https://issues.apache.org/jira/browse/HBASE-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168805#comment-14168805 ] stack commented on HBASE-11912: --- The clusterstatus changes and the deprecations are related? If so +1. Try it? Catch some bad practices at compile time with error-prone - Key: HBASE-11912 URL: https://issues.apache.org/jira/browse/HBASE-11912 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Attachments: HBASE-11912.patch, HBASE-11912.patch Google's error-prone (https://code.google.com/p/error-prone/) wraps javac with some additional static analysis that will generate additional warnings or errors at compile time if certain bug patterns (https://code.google.com/p/error-prone/wiki/BugPatterns) are detected. What's nice about this approach, as opposed to findbugs, is the compile time detection and erroring out prevent the detected problems from getting into the codebase up front. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11912) Catch some bad practices at compile time with error-prone
[ https://issues.apache.org/jira/browse/HBASE-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168808#comment-14168808 ] stack commented on HBASE-11912: --- We can turn on the experimental features after we've run w/ the defaults a while. Catch some bad practices at compile time with error-prone - Key: HBASE-11912 URL: https://issues.apache.org/jira/browse/HBASE-11912 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Attachments: HBASE-11912.patch, HBASE-11912.patch Google's error-prone (https://code.google.com/p/error-prone/) wraps javac with some additional static analysis that will generate additional warnings or errors at compile time if certain bug patterns (https://code.google.com/p/error-prone/wiki/BugPatterns) are detected. What's nice about this approach, as opposed to findbugs, is the compile time detection and erroring out prevent the detected problems from getting into the codebase up front. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12083) Deprecate new HBaseAdmin() in favor of Connection.getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-12083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168824#comment-14168824 ] stack commented on HBASE-12083: --- Logical next step I'd say [~enis] Should be done for 1.0 IMO. On commit, change this wording '...public visible class'. You are saying it is NOT visable yet it remains public... Need a bit more wording to explain difference between public class and private visability? Point at refguide? Nice cleanup. Deprecate new HBaseAdmin() in favor of Connection.getAdmin() Key: HBASE-12083 URL: https://issues.apache.org/jira/browse/HBASE-12083 Project: HBase Issue Type: Bug Reporter: Solomon Duskis Assignee: Solomon Duskis Priority: Critical Fix For: 2.0.0, 0.99.2 Attachments: hbase-12083_v1.patch, hbase-12083_v2.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11890) HBase REST Client is hard coded to http protocol
[ https://issues.apache.org/jira/browse/HBASE-11890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168884#comment-14168884 ] stack commented on HBASE-11890: --- [~tianq] Pardon me. Thanks for poke. Committed to master. HBase REST Client is hard coded to http protocol Key: HBASE-11890 URL: https://issues.apache.org/jira/browse/HBASE-11890 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.96.2 Reporter: Eric Yang Assignee: Qiang Tian Fix For: 2.0.0, 0.98.7, 0.99.1 Attachments: HBase-11890-doc.patch, HBase-11890-master-v1.patch, HBase-11890-master.patch HBase REST Client executePathOnly only supports http. It would be nice if there is a option to enable REST API client to connect through SSL. org.apache.hadoop.hbase.rest.client.Cluster class does not indicate which protocol can be used, we can either set flag in Cluster class or introduce a parameter in Client class to toggle SSL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12235) Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits should test correct region
[
https://issues.apache.org/jira/browse/HBASE-12235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-12235:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to 0.94 Thanks mighty Sean.
Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits
should test correct region
-
Key: HBASE-12235
URL: https://issues.apache.org/jira/browse/HBASE-12235
Project: HBase
Issue Type: Task
Components: test
Affects Versions: 0.94.0
Environment: 0.94.15 compiled with jdk6 running on jdk7 (but I don't
think it's relevant)
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Minor
Fix For: 0.94.25
Attachments: HBASE-12235-0.94.1.patch.txt
I had TestDistributedLogSplitting.testRecoveredEdits fail on a internal test
rig. It's very infrequent.
The proximal failure looks like HBASE-9002, the assertion finds 0 edits
instead of 1000.
Looking through the logs, the #regions printed is 1
{code}
line 236LOG.info(#regions = + regions.size());
{code}
And then in the makeHLog method I never see any log entry for the actual
writing
{code}
line 569for (int i = 0; i n; i++) {
line 570 LOG.info(region + hris.get(i).getRegionNameAsString() +
has + counts[i] + edits);
line 571}
{code}
I think what's happening is we're picking a region that is META or ROOT, so
the checks after the #regions= line removes the region and we end up
inserting no data.
It looks like the patch for HBASE-9002 should fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12234: -- Resolution: Fixed Fix Version/s: 0.99.2 0.98.8 2.0.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to 0.98+. Thanks for patch [~eclark] Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.98.8, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12223) MultiTableInputFormatBase.getSplits is too slow
[ https://issues.apache.org/jira/browse/HBASE-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengyuanbo updated HBASE-12223: --- Attachment: (was: HBASE-12223.patch) MultiTableInputFormatBase.getSplits is too slow --- Key: HBASE-12223 URL: https://issues.apache.org/jira/browse/HBASE-12223 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.94.15 Reporter: shanwen Priority: Minor Fix For: 2.0.0, 0.98.8, 0.94.25, 0.99.2 when use Multiple scan,getSplits is too slow,800 scans take five minutes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12223) MultiTableInputFormatBase.getSplits is too slow
[ https://issues.apache.org/jira/browse/HBASE-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168897#comment-14168897 ] pengyuanbo commented on HBASE-12223: Hi,Ted Yu.I have updated HBASE-12223.patch MultiTableInputFormatBase.getSplits is too slow --- Key: HBASE-12223 URL: https://issues.apache.org/jira/browse/HBASE-12223 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.94.15 Reporter: shanwen Priority: Minor Fix For: 2.0.0, 0.98.8, 0.94.25, 0.99.2 Attachments: HBASE-12223.patch when use Multiple scan,getSplits is too slow,800 scans take five minutes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12223) MultiTableInputFormatBase.getSplits is too slow
[ https://issues.apache.org/jira/browse/HBASE-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengyuanbo updated HBASE-12223: --- Attachment: HBASE-12223.patch MultiTableInputFormatBase.getSplits is too slow --- Key: HBASE-12223 URL: https://issues.apache.org/jira/browse/HBASE-12223 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.94.15 Reporter: shanwen Priority: Minor Fix For: 2.0.0, 0.98.8, 0.94.25, 0.99.2 Attachments: HBASE-12223.patch when use Multiple scan,getSplits is too slow,800 scans take five minutes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168898#comment-14168898 ] Hudson commented on HBASE-12234: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #565 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/565/]) HBASE-12234 Make TestMultithreadedTableMapper a little more stable. (stack: rev c47c6bdf0b8c5c245840c3791ddda6bfd8b0d3d5) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultithreadedTableMapper.java Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.98.8, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12238) A few ugly exceptions on startup
stack created HBASE-12238:
-
Summary: A few ugly exceptions on startup
Key: HBASE-12238
URL: https://issues.apache.org/jira/browse/HBASE-12238
Project: HBase
Issue Type: Bug
Affects Versions: 0.99.1
Reporter: stack
Assignee: stack
Fix For: 0.99.2
Let me fix a few innocuous exceptions that show on startup (saw testing
0.99.1), even when regular -- will throw people off.
Here is one:
{code}
2014-10-12 19:07:15,251 INFO [c2020:16020.activeMasterManager]
zookeeper.MetaTableLocator: Failed verification of hbase:meta,,1 at
address=c2021.halxg.cloudera.com,16020,1413165899611,
exception=org.apache.hadoop.hbase.NotServingRegionException:
org.apache.hadoop.hbase.NotServingRegionException: Region hbase:meta,,1 is not
online on c2021.halxg.cloudera.com,16020,1413166029547
at
org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:2677)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:838)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegionInfo(RSRpcServices.java:1110)
at
org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:20158)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2016)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
at
org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:110)
at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:90)
at java.lang.Thread.run(Thread.java:745)
{code}
More to follow...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168901#comment-14168901 ] Hudson commented on HBASE-12234: FAILURE: Integrated in HBase-0.98 #594 (See [https://builds.apache.org/job/HBase-0.98/594/]) HBASE-12234 Make TestMultithreadedTableMapper a little more stable. (stack: rev c47c6bdf0b8c5c245840c3791ddda6bfd8b0d3d5) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultithreadedTableMapper.java Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.98.8, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12234: -- Fix Version/s: (was: 0.98.8) Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168906#comment-14168906 ] stack commented on HBASE-12234: --- Reverted from 0.98... don't have the wait in HBaseTestingUtility this patch calls. Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12238) A few ugly exceptions on startup
[
https://issues.apache.org/jira/browse/HBASE-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168907#comment-14168907
]
stack commented on HBASE-12238:
---
In standalone mode this is a little disorientating... it shows up frequently:
{code}
143 2014-10-07 16:57:28,814 INFO
[M:0;192.168.1.225:54811-SendThread(fe80:0:0:0:0:0:0:1%1:2181)]
zookeeper.ClientCnxn: Opening socket connection to server
fe80:0:0:0:0:0:0:1%1/fe80:0:0:0:0:0:0:1%1:2181. Will not attempt to
authenticate using SASL (unknown error)
144 2014-10-07 16:57:28,815 INFO
[M:0;192.168.1.225:54811-SendThread(fe80:0:0:0:0:0:0:1%1:2181)]
zookeeper.ClientCnxn: Client session timed out, have not heard from server in
5076ms for sessionid 0x0, closing socket connection and attempting reconnect
145 2014-10-07 16:57:28,815 INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181]
server.NIOServerCnxnFactory: Accepted socket connection from
/fe80:0:0:0:0:0:0:1%1:54823
146 2014-10-07 16:57:28,815 WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181]
server.NIOServerCnxn: caught end of stream exception
147 EndOfStreamException: Unable to read additional data from client sessionid
0x0, likely client has closed socket
148 at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
149 at
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
150 at java.lang.Thread.run(Thread.java:745)
{code}
A few ugly exceptions on startup
Key: HBASE-12238
URL: https://issues.apache.org/jira/browse/HBASE-12238
Project: HBase
Issue Type: Bug
Affects Versions: 0.99.1
Reporter: stack
Assignee: stack
Fix For: 0.99.2
Let me fix a few innocuous exceptions that show on startup (saw testing
0.99.1), even when regular -- will throw people off.
Here is one:
{code}
2014-10-12 19:07:15,251 INFO [c2020:16020.activeMasterManager]
zookeeper.MetaTableLocator: Failed verification of hbase:meta,,1 at
address=c2021.halxg.cloudera.com,16020,1413165899611,
exception=org.apache.hadoop.hbase.NotServingRegionException:
org.apache.hadoop.hbase.NotServingRegionException: Region hbase:meta,,1 is
not online on c2021.halxg.cloudera.com,16020,1413166029547
at
org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:2677)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:838)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegionInfo(RSRpcServices.java:1110)
at
org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:20158)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2016)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
at
org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:110)
at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:90)
at java.lang.Thread.run(Thread.java:745)
{code}
More to follow...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12235) Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits should test correct region
[
https://issues.apache.org/jira/browse/HBASE-12235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168912#comment-14168912
]
Hudson commented on HBASE-12235:
SUCCESS: Integrated in HBase-0.94-security #548 (See
[https://builds.apache.org/job/HBase-0.94-security/548/])
HBASE-12235 Backport to 0.94: HBASE-9002
TestDistributedLogSplitting.testRecoverdEdits should test correct region (Sean
Busbey) (stack: rev 45eb18ba5eda6c66e0b53377b9722b062cd3ee3c)
* src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java
Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits
should test correct region
-
Key: HBASE-12235
URL: https://issues.apache.org/jira/browse/HBASE-12235
Project: HBase
Issue Type: Task
Components: test
Affects Versions: 0.94.0
Environment: 0.94.15 compiled with jdk6 running on jdk7 (but I don't
think it's relevant)
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Minor
Fix For: 0.94.25
Attachments: HBASE-12235-0.94.1.patch.txt
I had TestDistributedLogSplitting.testRecoveredEdits fail on a internal test
rig. It's very infrequent.
The proximal failure looks like HBASE-9002, the assertion finds 0 edits
instead of 1000.
Looking through the logs, the #regions printed is 1
{code}
line 236LOG.info(#regions = + regions.size());
{code}
And then in the makeHLog method I never see any log entry for the actual
writing
{code}
line 569for (int i = 0; i n; i++) {
line 570 LOG.info(region + hris.get(i).getRegionNameAsString() +
has + counts[i] + edits);
line 571}
{code}
I think what's happening is we're picking a region that is META or ROOT, so
the checks after the #regions= line removes the region and we end up
inserting no data.
It looks like the patch for HBASE-9002 should fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-9002) TestDistributedLogSplitting.testRecoveredEdits fails
[
https://issues.apache.org/jira/browse/HBASE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168911#comment-14168911
]
Hudson commented on HBASE-9002:
---
SUCCESS: Integrated in HBase-0.94-security #548 (See
[https://builds.apache.org/job/HBase-0.94-security/548/])
HBASE-12235 Backport to 0.94: HBASE-9002
TestDistributedLogSplitting.testRecoverdEdits should test correct region (Sean
Busbey) (stack: rev 45eb18ba5eda6c66e0b53377b9722b062cd3ee3c)
* src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java
TestDistributedLogSplitting.testRecoveredEdits fails
Key: HBASE-9002
URL: https://issues.apache.org/jira/browse/HBASE-9002
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jeffrey Zhong
Fix For: 0.96.0
Attachments: hbase-9002.patch
https://builds.apache.org/job/hbase-0.95/342/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testRecoveredEdits/
{code}
java.lang.AssertionError: expected:1000 but was:0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testRecoveredEdits(TestDistributedLogSplitting.java:209)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{code}
[~jxiang] or [~jeffreyz] want to take a look at this one?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-11890) HBase REST Client is hard coded to http protocol
[ https://issues.apache.org/jira/browse/HBASE-11890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168914#comment-14168914 ] Hudson commented on HBASE-11890: FAILURE: Integrated in HBase-TRUNK #5652 (See [https://builds.apache.org/job/HBase-TRUNK/5652/]) HBASE-11890 HBase REST Client is hard coded to http protocol (Qiang Tian) (stack: rev f2d05befad075f2b524ed6303cc782325dc361d6) * src/main/docbkx/external_apis.xml HBase REST Client is hard coded to http protocol Key: HBASE-11890 URL: https://issues.apache.org/jira/browse/HBASE-11890 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.96.2 Reporter: Eric Yang Assignee: Qiang Tian Fix For: 2.0.0, 0.98.7, 0.99.1 Attachments: HBase-11890-doc.patch, HBase-11890-master-v1.patch, HBase-11890-master.patch HBase REST Client executePathOnly only supports http. It would be nice if there is a option to enable REST API client to connect through SSL. org.apache.hadoop.hbase.rest.client.Cluster class does not indicate which protocol can be used, we can either set flag in Cluster class or introduce a parameter in Client class to toggle SSL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168913#comment-14168913 ] Hudson commented on HBASE-12234: FAILURE: Integrated in HBase-TRUNK #5652 (See [https://builds.apache.org/job/HBase-TRUNK/5652/]) HBASE-12234 Make TestMultithreadedTableMapper a little more stable. (stack: rev ab42b9ffe614ace7e7c9707c6467e168ce055c50) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultithreadedTableMapper.java Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12235) Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits should test correct region
[
https://issues.apache.org/jira/browse/HBASE-12235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168918#comment-14168918
]
Hudson commented on HBASE-12235:
SUCCESS: Integrated in HBase-0.94-JDK7 #203 (See
[https://builds.apache.org/job/HBase-0.94-JDK7/203/])
HBASE-12235 Backport to 0.94: HBASE-9002
TestDistributedLogSplitting.testRecoverdEdits should test correct region (Sean
Busbey) (stack: rev 45eb18ba5eda6c66e0b53377b9722b062cd3ee3c)
* src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java
Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits
should test correct region
-
Key: HBASE-12235
URL: https://issues.apache.org/jira/browse/HBASE-12235
Project: HBase
Issue Type: Task
Components: test
Affects Versions: 0.94.0
Environment: 0.94.15 compiled with jdk6 running on jdk7 (but I don't
think it's relevant)
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Minor
Fix For: 0.94.25
Attachments: HBASE-12235-0.94.1.patch.txt
I had TestDistributedLogSplitting.testRecoveredEdits fail on a internal test
rig. It's very infrequent.
The proximal failure looks like HBASE-9002, the assertion finds 0 edits
instead of 1000.
Looking through the logs, the #regions printed is 1
{code}
line 236LOG.info(#regions = + regions.size());
{code}
And then in the makeHLog method I never see any log entry for the actual
writing
{code}
line 569for (int i = 0; i n; i++) {
line 570 LOG.info(region + hris.get(i).getRegionNameAsString() +
has + counts[i] + edits);
line 571}
{code}
I think what's happening is we're picking a region that is META or ROOT, so
the checks after the #regions= line removes the region and we end up
inserting no data.
It looks like the patch for HBASE-9002 should fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-9002) TestDistributedLogSplitting.testRecoveredEdits fails
[
https://issues.apache.org/jira/browse/HBASE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168917#comment-14168917
]
Hudson commented on HBASE-9002:
---
SUCCESS: Integrated in HBase-0.94-JDK7 #203 (See
[https://builds.apache.org/job/HBase-0.94-JDK7/203/])
HBASE-12235 Backport to 0.94: HBASE-9002
TestDistributedLogSplitting.testRecoverdEdits should test correct region (Sean
Busbey) (stack: rev 45eb18ba5eda6c66e0b53377b9722b062cd3ee3c)
* src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java
TestDistributedLogSplitting.testRecoveredEdits fails
Key: HBASE-9002
URL: https://issues.apache.org/jira/browse/HBASE-9002
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jeffrey Zhong
Fix For: 0.96.0
Attachments: hbase-9002.patch
https://builds.apache.org/job/hbase-0.95/342/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testRecoveredEdits/
{code}
java.lang.AssertionError: expected:1000 but was:0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testRecoveredEdits(TestDistributedLogSplitting.java:209)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{code}
[~jxiang] or [~jeffreyz] want to take a look at this one?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12235) Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits should test correct region
[
https://issues.apache.org/jira/browse/HBASE-12235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168922#comment-14168922
]
Hudson commented on HBASE-12235:
FAILURE: Integrated in HBase-0.94 #1434 (See
[https://builds.apache.org/job/HBase-0.94/1434/])
HBASE-12235 Backport to 0.94: HBASE-9002
TestDistributedLogSplitting.testRecoverdEdits should test correct region (Sean
Busbey) (stack: rev 45eb18ba5eda6c66e0b53377b9722b062cd3ee3c)
* src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java
Backport to 0.94: HBASE-9002 TestDistributedLogSplitting.testRecoverdEdits
should test correct region
-
Key: HBASE-12235
URL: https://issues.apache.org/jira/browse/HBASE-12235
Project: HBase
Issue Type: Task
Components: test
Affects Versions: 0.94.0
Environment: 0.94.15 compiled with jdk6 running on jdk7 (but I don't
think it's relevant)
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Minor
Fix For: 0.94.25
Attachments: HBASE-12235-0.94.1.patch.txt
I had TestDistributedLogSplitting.testRecoveredEdits fail on a internal test
rig. It's very infrequent.
The proximal failure looks like HBASE-9002, the assertion finds 0 edits
instead of 1000.
Looking through the logs, the #regions printed is 1
{code}
line 236LOG.info(#regions = + regions.size());
{code}
And then in the makeHLog method I never see any log entry for the actual
writing
{code}
line 569for (int i = 0; i n; i++) {
line 570 LOG.info(region + hris.get(i).getRegionNameAsString() +
has + counts[i] + edits);
line 571}
{code}
I think what's happening is we're picking a region that is META or ROOT, so
the checks after the #regions= line removes the region and we end up
inserting no data.
It looks like the patch for HBASE-9002 should fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-9002) TestDistributedLogSplitting.testRecoveredEdits fails
[
https://issues.apache.org/jira/browse/HBASE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168921#comment-14168921
]
Hudson commented on HBASE-9002:
---
FAILURE: Integrated in HBase-0.94 #1434 (See
[https://builds.apache.org/job/HBase-0.94/1434/])
HBASE-12235 Backport to 0.94: HBASE-9002
TestDistributedLogSplitting.testRecoverdEdits should test correct region (Sean
Busbey) (stack: rev 45eb18ba5eda6c66e0b53377b9722b062cd3ee3c)
* src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java
TestDistributedLogSplitting.testRecoveredEdits fails
Key: HBASE-9002
URL: https://issues.apache.org/jira/browse/HBASE-9002
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jeffrey Zhong
Fix For: 0.96.0
Attachments: hbase-9002.patch
https://builds.apache.org/job/hbase-0.95/342/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testRecoveredEdits/
{code}
java.lang.AssertionError: expected:1000 but was:0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testRecoveredEdits(TestDistributedLogSplitting.java:209)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{code}
[~jxiang] or [~jeffreyz] want to take a look at this one?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168927#comment-14168927 ] Hudson commented on HBASE-12234: SUCCESS: Integrated in HBase-1.0 #301 (See [https://builds.apache.org/job/HBase-1.0/301/]) HBASE-12234 Make TestMultithreadedTableMapper a little more stable. (stack: rev e0085d85ae1904adda82b98059bbc19ea7372bb1) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultithreadedTableMapper.java Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12239) Document hedged reads
Misty Stanley-Jones created HBASE-12239: --- Summary: Document hedged reads Key: HBASE-12239 URL: https://issues.apache.org/jira/browse/HBASE-12239 Project: HBase Issue Type: Task Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12239) Document hedged reads
[ https://issues.apache.org/jira/browse/HBASE-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-12239: Attachment: HBASE-12239.patch Please review, [~jmhsieh] et al. Document hedged reads - Key: HBASE-12239 URL: https://issues.apache.org/jira/browse/HBASE-12239 Project: HBase Issue Type: Task Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Attachments: HBASE-12239.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12239) Document hedged reads
[ https://issues.apache.org/jira/browse/HBASE-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-12239: Status: Patch Available (was: Open) Document hedged reads - Key: HBASE-12239 URL: https://issues.apache.org/jira/browse/HBASE-12239 Project: HBase Issue Type: Task Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Attachments: HBASE-12239.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-6970) hbase-deamon.sh creates/updates pid file even when that start failed.
[
https://issues.apache.org/jira/browse/HBASE-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi reassigned HBASE-6970:
Assignee: Ashish Singhi
hbase-deamon.sh creates/updates pid file even when that start failed.
-
Key: HBASE-6970
URL: https://issues.apache.org/jira/browse/HBASE-6970
Project: HBase
Issue Type: Bug
Components: Usability
Reporter: Lars Hofhansl
Assignee: Ashish Singhi
Fix For: 2.0.0
We just ran into a strange issue where could neither start nor stop services
with hbase-deamon.sh.
The problem is this:
{code}
nohup nice -n $HBASE_NICENESS $HBASE_HOME/bin/hbase \
--config ${HBASE_CONF_DIR} \
$command $@ $startStop $logout 21 /dev/null
echo $! $pid
{code}
So the pid file is created or updated even when the start of the service
failed. The next stop command will then fail, because the pid file has the
wrong pid in it.
Edit: Spelling and more spelling errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168953#comment-14168953 ] Hudson commented on HBASE-12234: FAILURE: Integrated in HBase-0.98 #595 (See [https://builds.apache.org/job/HBase-0.98/595/]) HBASE-12234 Make TestMultithreadedTableMapper a little more stable -- REVERT. (stack: rev 5e1801b56b844958c9d11460e493d29c4be8ed2f) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultithreadedTableMapper.java Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-8361) Bulk load and other utilities should not create tables for user
[
https://issues.apache.org/jira/browse/HBASE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-8361:
-
Resolution: Fixed
Fix Version/s: 0.99.2
0.98.8
2.0.0
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Nice patch. Thanks Ashish. Applied to 0.98+
Bulk load and other utilities should not create tables for user
---
Key: HBASE-8361
URL: https://issues.apache.org/jira/browse/HBASE-8361
Project: HBase
Issue Type: Improvement
Components: mapreduce
Reporter: Nick Dimiduk
Assignee: Ashish Singhi
Fix For: 2.0.0, 0.98.8, 0.99.2
Attachments: HBASE-8361.patch
{{LoadIncrementalHFiles}} and {{ImportTsv}} will create a table with the
default setting when the target table does not exist. I think this is an
anti-feature. Neither tool provide a mechanism for the user to configure the
creation parameters of that table, resulting in a new table with the default
settings. I think it is unlikely that the default settings are what the user
actually wants. In the event of a table-name typo, that means data is
silently loaded into the wrong place. The tools should error when the
destination table does not exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-6970) hbase-deamon.sh creates/updates pid file even when that start failed.
[
https://issues.apache.org/jira/browse/HBASE-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168956#comment-14168956
]
Ashish Singhi commented on HBASE-6970:
--
bq. stop command does not return a failed exit code ( 0), if the stop fails
because the running process was not found.
I think we should not return a failed exit code in this case. If we do then
user may assume that the process is still running but it is not.
hbase-deamon.sh creates/updates pid file even when that start failed.
-
Key: HBASE-6970
URL: https://issues.apache.org/jira/browse/HBASE-6970
Project: HBase
Issue Type: Bug
Components: Usability
Reporter: Lars Hofhansl
Assignee: Ashish Singhi
Fix For: 2.0.0
We just ran into a strange issue where could neither start nor stop services
with hbase-deamon.sh.
The problem is this:
{code}
nohup nice -n $HBASE_NICENESS $HBASE_HOME/bin/hbase \
--config ${HBASE_CONF_DIR} \
$command $@ $startStop $logout 21 /dev/null
echo $! $pid
{code}
So the pid file is created or updated even when the start of the service
failed. The next stop command will then fail, because the pid file has the
wrong pid in it.
Edit: Spelling and more spelling errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-8361) Bulk load and other utilities should not create tables for user
[
https://issues.apache.org/jira/browse/HBASE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168958#comment-14168958
]
Ashish Singhi commented on HBASE-8361:
--
Thanks for review and commit Stack.
Bulk load and other utilities should not create tables for user
---
Key: HBASE-8361
URL: https://issues.apache.org/jira/browse/HBASE-8361
Project: HBase
Issue Type: Improvement
Components: mapreduce
Reporter: Nick Dimiduk
Assignee: Ashish Singhi
Fix For: 2.0.0, 0.98.8, 0.99.2
Attachments: HBASE-8361.patch
{{LoadIncrementalHFiles}} and {{ImportTsv}} will create a table with the
default setting when the target table does not exist. I think this is an
anti-feature. Neither tool provide a mechanism for the user to configure the
creation parameters of that table, resulting in a new table with the default
settings. I think it is unlikely that the default settings are what the user
actually wants. In the event of a table-name typo, that means data is
silently loaded into the wrong place. The tools should error when the
destination table does not exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-12240) hbase-daemon.sh should remove pid file if process not found running
Ashish Singhi created HBASE-12240:
-
Summary: hbase-daemon.sh should remove pid file if process not
found running
Key: HBASE-12240
URL: https://issues.apache.org/jira/browse/HBASE-12240
Project: HBase
Issue Type: Bug
Components: Usability
Reporter: Ashish Singhi
Assignee: Ashish Singhi
Priority: Minor
{{stop-hbase.sh}} removes process pid file irrespective of whether process is
running or not.
Same should be the behavior with {{hbase-daemon.sh stop}} command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12239) Document hedged reads
[ https://issues.apache.org/jira/browse/HBASE-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168962#comment-14168962 ] stack commented on HBASE-12239: --- Excellent +1. Remove this on commit 'hedgedReadOpsInCurThread'. This metric is not exposed. See tail of hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionServerSource.java Document hedged reads - Key: HBASE-12239 URL: https://issues.apache.org/jira/browse/HBASE-12239 Project: HBase Issue Type: Task Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Attachments: HBASE-12239.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12240) hbase-daemon.sh should remove pid file if process not found running
[
https://issues.apache.org/jira/browse/HBASE-12240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi updated HBASE-12240:
--
Attachment: HBASE-12240.patch
A very simple patch.
Please some one review.
hbase-daemon.sh should remove pid file if process not found running
---
Key: HBASE-12240
URL: https://issues.apache.org/jira/browse/HBASE-12240
Project: HBase
Issue Type: Bug
Components: Usability
Reporter: Ashish Singhi
Assignee: Ashish Singhi
Priority: Minor
Attachments: HBASE-12240.patch
{{stop-hbase.sh}} removes process pid file irrespective of whether process is
running or not.
Same should be the behavior with {{hbase-daemon.sh stop}} command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-10201) Port 'Make flush decisions per column family' to trunk
[ https://issues.apache.org/jira/browse/HBASE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangduo updated HBASE-10201: - Attachment: HBASE-10201-0.98.patch I port the 3149-trunk-v1.txt patch to branch 0.98(a just make it work version, not the final version). Port to master is more difficult because of the rewrite of HLog. Flush per CF means we need to record the oldest sequence id per store instead of per region, so the patch add a seqNum parameter when add kv to store, which means we need to know the seqNum before we add kv to store. It is easy on branch 0.98, just need to change the order of appendNoSync of wal and write back to memstore(am I right?). But on master, HLog seems to use a event-driven framework, and I am not sure when will the seqNum be determined. The second problem is the flushSeqId. on 0.98, it is just a simple incAndGet, but on master it uses a method in HLog. So on 0.98, if we only flush some of the stores, we can set the flushSeqId to the oldest seqNum stored in the stores that not being flushed and do not inc sequenceId. But on master, I do not know the side effect of the method.Is it ok to remove the method call, or we still need to log something? Port 'Make flush decisions per column family' to trunk -- Key: HBASE-10201 URL: https://issues.apache.org/jira/browse/HBASE-10201 Project: HBase Issue Type: Improvement Reporter: Ted Yu Attachments: 3149-trunk-v1.txt, HBASE-10201-0.98.patch Currently the flush decision is made using the aggregate size of all column families. When large and small column families co-exist, this causes many small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12234) Make TestMultithreadedTableMapper a little more stable.
[ https://issues.apache.org/jira/browse/HBASE-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168971#comment-14168971 ] Hudson commented on HBASE-12234: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #566 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/566/]) HBASE-12234 Make TestMultithreadedTableMapper a little more stable -- REVERT. (stack: rev 5e1801b56b844958c9d11460e493d29c4be8ed2f) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultithreadedTableMapper.java Make TestMultithreadedTableMapper a little more stable. --- Key: HBASE-12234 URL: https://issues.apache.org/jira/browse/HBASE-12234 Project: HBase Issue Type: Bug Affects Versions: 0.99.0, 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 2.0.0, 0.99.2 Attachments: 0001-HBASE-12234-Make-TestMultithreadedTableMapper-a-litt.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12239) Document hedged reads
[ https://issues.apache.org/jira/browse/HBASE-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168976#comment-14168976 ] Misty Stanley-Jones commented on HBASE-12239: - Committed to master with stack's feedback. Document hedged reads - Key: HBASE-12239 URL: https://issues.apache.org/jira/browse/HBASE-12239 Project: HBase Issue Type: Task Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Fix For: 2.0.0 Attachments: HBASE-12239.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12239) Document hedged reads
[ https://issues.apache.org/jira/browse/HBASE-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-12239: Resolution: Fixed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Document hedged reads - Key: HBASE-12239 URL: https://issues.apache.org/jira/browse/HBASE-12239 Project: HBase Issue Type: Task Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Fix For: 2.0.0 Attachments: HBASE-12239.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-12232) Suppress dots during svn commit in publish_hbase_website.sh script
[ https://issues.apache.org/jira/browse/HBASE-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones reassigned HBASE-12232: --- Assignee: Misty Stanley-Jones Suppress dots during svn commit in publish_hbase_website.sh script -- Key: HBASE-12232 URL: https://issues.apache.org/jira/browse/HBASE-12232 Project: HBase Issue Type: Task Components: documentation, scripts Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Priority: Trivial Labels: newbie -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-5742) LoadIncrementalHFiles throws too generic of an exception
[
https://issues.apache.org/jira/browse/HBASE-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168979#comment-14168979
]
Ashish Singhi commented on HBASE-5742:
--
I checked this in the master branch. ZooKeeperConnectionException and
MasterNotRunningException will actually be never thrown. They exist just to
avoid backward incompatibility as the java doc also says
{code}
@throws MasterNotRunningException, ZooKeeperConnectionException are not
* thrown anymore but kept into the interface for backward api
compatibility{code}
Should we resolve this as Won't fix ?
LoadIncrementalHFiles throws too generic of an exception
Key: HBASE-5742
URL: https://issues.apache.org/jira/browse/HBASE-5742
Project: HBase
Issue Type: Improvement
Components: mapreduce
Reporter: David Capwell
Assignee: Ashish Singhi
In 0.90 the LoadIncrementalHFiles constructor did not throw an exception, now
it throws Exception. The constructor should ether not throw an exception or
throw ZooKeeperConnectionException, and MasterNotRunningException since those
come from the HBaseAdmin call.
https://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java#L105
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
