[jira] [Created] (HBASE-18045) Add ' -o ConnectTimeout=10' to the ssh command we use in ITBLL chaos monkeys
stack created HBASE-18045: - Summary: Add ' -o ConnectTimeout=10' to the ssh command we use in ITBLL chaos monkeys Key: HBASE-18045 URL: https://issues.apache.org/jira/browse/HBASE-18045 Project: HBase Issue Type: Improvement Components: integration tests Reporter: stack Priority: Trivial Monkeys hang on me in long running tests. I've not spent too much time on it since it rare enough but I just went through a spate of them. When monkey kill ssh hangs, all killing stops which can give a false sense of victory when you wake up in the morning and your job 'passed'. I also see monkeys kill all servers in a cluster and fail to bring them back which causes job fail as no one is serving data. The latter may actually be another issue but for the former, I've had some success adding -o ConnectTimeout=10 as an option on ssh. You can do it easily enough via config but this issue is to suggest that we add it in code. Here is how you add it via config if interested: hbase.it.clustermanager.ssh.opts -o ConnectTimeout=10 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18044) Bug fix in flaky-dashboard-template
Appy created HBASE-18044: Summary: Bug fix in flaky-dashboard-template Key: HBASE-18044 URL: https://issues.apache.org/jira/browse/HBASE-18044 Project: HBase Issue Type: Bug Reporter: Appy Assignee: Appy Priority: Minor Due to some scoping issues, counters don't work in jinja templates like we expect them to (in java/c++,etc). (http://stackoverflow.com/questions/7537439/how-to-increment-a-variable-on-a-for-loop-in-jinja-template). Due to this, clicking show/hide button for tests which fail in multiple urls will not work sometime. Fixing it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18043) Institute a hard limit for individual cell size that cannot be overridden by clients
Andrew Purtell created HBASE-18043: -- Summary: Institute a hard limit for individual cell size that cannot be overridden by clients Key: HBASE-18043 URL: https://issues.apache.org/jira/browse/HBASE-18043 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 2.0.0, 1.4.0 For sake of service protection we should not give absolute trust to clients regarding resource limits that can impact stability, like cell size limits. We should add a server side configuration that sets a hard limit for individual cell size that cannot be overridden by the client. We can keep the client side check, because it's expensive to reject a RPC that has already come in. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18042) Client Compatibility breaks between versions 1.2 and 1.3
Karan Mehta created HBASE-18042:
---
Summary: Client Compatibility breaks between versions 1.2 and 1.3
Key: HBASE-18042
URL: https://issues.apache.org/jira/browse/HBASE-18042
Project: HBase
Issue Type: Bug
Reporter: Karan Mehta
OpenTSDB uses AsyncHBase as its client, rather than using the traditional HBase
Client. From version 1.2 to 1.3, the {{ClientProtos}} have been changed. Newer
fields are added to {{ScanResponse}} proto.
For a typical Scan request in 1.2, would require caller to make an OpenScanner
Request, GetNextRows Request and a CloseScanner Request, based on {{more_rows}}
boolean field in the {{ScanResponse}} proto.
However, from 1.3, new parameter {{more_results_in_region}} was added, which
limits the results per region. Therefore the client has to now manage sending
all the requests for each region. Further more, if the results are exhausted
from a particular region, the {{ScanResponse}} will set
{{more_results_in_region}} to false, but {{more_results}} can still be true.
Whenever the former is set to false, the {{RegionScanner}} will also be closed.
OpenTSDB makes an OpenScanner Request and receives all its results in the first
{{ScanResponse}} itself, thus creating a condition as described in above
paragraph. Since {{more_rows}} is true, it will proceed to send next request at
which point the {{RSRpcServices}} will throw {{UnknownScannerException}}. The
protobuf client compatibility is maintained but expected behavior is modified.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18041) Add pylintrc file to HBase
Alex Leblang created HBASE-18041: Summary: Add pylintrc file to HBase Key: HBASE-18041 URL: https://issues.apache.org/jira/browse/HBASE-18041 Project: HBase Issue Type: Improvement Reporter: Alex Leblang Yetis runs all commits with python files through a linter. I think that the HBase community should add a pylintrc file to actively choose the project's python style instead of just relying on yetis defaults. As an argument for this, the yetis project itself doesn't even use the default python linter for its own commits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18040) TestBlockEvictionFromClient fails in master branch
Ted Yu created HBASE-18040:
--
Summary: TestBlockEvictionFromClient fails in master branch
Key: HBASE-18040
URL: https://issues.apache.org/jira/browse/HBASE-18040
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
According to
https://builds.apache.org/job/HBASE-Flaky-Tests/16000/#showFailuresLink , the
test first failed with commit 0ae0edcd630aa1dcb6c47ea11fa4367ae0a5baa8
On Linux, I got the following failures:
{code}
testParallelGetsAndScans(org.apache.hadoop.hbase.client.TestBlockEvictionFromClient)
Time elapsed: 3.016 sec <<< FAILURE!
java.lang.AssertionError: expected:<3> but was:<6>
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.checkForBlockEviction(TestBlockEvictionFromClient.java:1308)
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testParallelGetsAndScans(TestBlockEvictionFromClient.java:293)
testBlockRefCountAfterSplits(org.apache.hadoop.hbase.client.TestBlockEvictionFromClient)
Time elapsed: 7.786 sec <<< FAILURE!
java.lang.AssertionError: expected:<0> but was:<1>
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.iterateBlockCache(TestBlockEvictionFromClient.java:1215)
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testBlockRefCountAfterSplits(TestBlockEvictionFromClient.java:607)
testParallelGetsAndScanWithWrappedRegionScanner(org.apache.hadoop.hbase.client.TestBlockEvictionFromClient)
Time elapsed: 2.631 sec <<< FAILURE!
java.lang.AssertionError: expected:<3> but was:<6>
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.checkForBlockEviction(TestBlockEvictionFromClient.java:1322)
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testParallelGetsAndScanWithWrappedRegionScanner(TestBlockEvictionFromClient.java:839)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
Re: How to find the rowkey of a table in HBASE
You issue a Get request for the rowkey you're looking for (checking for existence) or your use a Scanner to read all rowkeys (data) in the table. Developer Brasil wrote: How to find the rowkey of a table in HBASE -- View this message in context: http://apache-hbase.679495.n3.nabble.com/How-to-find-the-rowkey-of-a-table-in-HBASE-tp4087915.html Sent from the HBase Developer mailing list archive at Nabble.com.
[jira] [Resolved] (HBASE-18039) Create a copy of AccessControl.proto under hbase-protocol-shaed module
[ https://issues.apache.org/jira/browse/HBASE-18039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu resolved HBASE-18039. -- Resolution: Duplicate > Create a copy of AccessControl.proto under hbase-protocol-shaed module > -- > > Key: HBASE-18039 > URL: https://issues.apache.org/jira/browse/HBASE-18039 > Project: HBase > Issue Type: Sub-task > Components: snapshots >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0 > > > 1. Create a copy of AccessControl.proto for hbase-protocol-shaded module. > 2. Move SnapshotDescription PB from HBase.proto to Snapshot.proto for > avoiding recursive import. > 3. Add an optional UsersAndPermissions field for SnapshotDescription. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-16075) TestAcidGuarantees is flaky
[ https://issues.apache.org/jira/browse/HBASE-16075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-16075. Resolution: Duplicate see HBASE-17887 > TestAcidGuarantees is flaky > --- > > Key: HBASE-16075 > URL: https://issues.apache.org/jira/browse/HBASE-16075 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov > > https://builds.apache.org/job/HBase-1.3/744/jdk=latest1.7,label=yahoo-not-h2/testReport/junit/TEST-org.apache.hadoop.hbase.TestAcidGuarantees/xml/_init_/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
