[jira] [Created] (HBASE-17263) Netty based rpc server impl
binlijin created HBASE-17263: Summary: Netty based rpc server impl Key: HBASE-17263 URL: https://issues.apache.org/jira/browse/HBASE-17263 Project: HBase Issue Type: Sub-task Reporter: binlijin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17262) Refactor RpcServer so as to make it extendable and/or pluggable
binlijin created HBASE-17262: Summary: Refactor RpcServer so as to make it extendable and/or pluggable Key: HBASE-17262 URL: https://issues.apache.org/jira/browse/HBASE-17262 Project: HBase Issue Type: Sub-task Reporter: binlijin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Time for Apache HBase 1.2.5
It can't be a blocker I don't think. We don't have a clear idea what's in error and how to fix. > On Dec 5, 2016, at 2:19 PM, Stack wrote: > >> On Mon, Dec 5, 2016 at 12:10 PM, Sean Busbey wrote: >> >> I have not, thanks for the heads-up. >> >> HBASE-17069 is currently not marked blocker and has no assignee. If >> it's a blocker for 1.2.5, could the folks involved please correct >> this? >> >> > Its not marked blocker because issue is under investigation still. > HBASE-14465 has been fingered as a problematic backport but it has been in > 1.2 since 1.2.0 committed more than a year ago. Seems important figuring > what is going on here -- I'm having trouble replicating -- but doesn't seem > like something to hold up a 1.2.5 for. > > St.Ack > > > > >>> On Mon, Dec 5, 2016 at 2:08 PM, Ted Yu wrote: >>> Sean: >>> Have you looked at HBASE-17069 ? >>> >>> Cheers >>> On Mon, Dec 5, 2016 at 12:05 PM, Sean Busbey wrote: Hi folks! I'm planning to cut an RC for 1.2.5 at the end of this week. I don't see any blockers in JIRA, so please let me know if there's something that ought to stop a release. - busbey >>
[jira] [Created] (HBASE-17261) Balancer makes no sense on tip of branch-1: says balanced when not
stack created HBASE-17261:
-
Summary: Balancer makes no sense on tip of branch-1: says balanced
when not
Key: HBASE-17261
URL: https://issues.apache.org/jira/browse/HBASE-17261
Project: HBase
Issue Type: Bug
Reporter: stack
Running ITBLL on tip of branch-1, I see this in log when I try to balance:
{code}
2016-12-05 16:42:21,031 INFO
[RpcServer.deafult.FPBQ.Fifo.handler=46,queue=1,port=16000]
balancer.StochasticLoadBalancer: Skipping load balancing because balanced
cluster; total cost is 525.2547686174673|
, sum multiplier is 111087.0 min cost which need balance is 0.05
{code}
Its some old nonsense.
Does this every time I balance. Can't even force a balance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-17218) [C++] Use Google Style guide and cpplint
[
https://issues.apache.org/jira/browse/HBASE-17218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar resolved HBASE-17218.
---
Resolution: Fixed
Fix Version/s: HBASE-14850
I have pushed this to the branch. [~xiaobingo], [~sudeeps] lets use
{code}
bin/format-code.sh
{code}
and
{code}
make lint
{code}
going forward for patches.
> [C++] Use Google Style guide and cpplint
>
>
> Key: HBASE-17218
> URL: https://issues.apache.org/jira/browse/HBASE-17218
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: HBASE-14850
>
> Attachments: HBASE-17218_v1.patch
>
>
> This was discussed elsewhere in other sub jiras. Let's use the Google's Style
> guide going forward (instead of LLVM one).
> There is an Eclipse formatter, a cpplint script and clang-format integration
> https://github.com/google/styleguide.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-17260) Procedure v2 - Add setOwner() overload taking a User instance
Matteo Bertozzi created HBASE-17260: --- Summary: Procedure v2 - Add setOwner() overload taking a User instance Key: HBASE-17260 URL: https://issues.apache.org/jira/browse/HBASE-17260 Project: HBase Issue Type: Sub-task Components: proc-v2 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Trivial Fix For: 2.0.0 since we should have a User instance in most of the cases, we should just be able to pass it, rather than converting it to getShortName() every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Time for Apache HBase 1.2.5
On Mon, Dec 5, 2016 at 12:10 PM, Sean Busbey wrote: > I have not, thanks for the heads-up. > > HBASE-17069 is currently not marked blocker and has no assignee. If > it's a blocker for 1.2.5, could the folks involved please correct > this? > > Its not marked blocker because issue is under investigation still. HBASE-14465 has been fingered as a problematic backport but it has been in 1.2 since 1.2.0 committed more than a year ago. Seems important figuring what is going on here -- I'm having trouble replicating -- but doesn't seem like something to hold up a 1.2.5 for. St.Ack > On Mon, Dec 5, 2016 at 2:08 PM, Ted Yu wrote: > > Sean: > > Have you looked at HBASE-17069 ? > > > > Cheers > > > > On Mon, Dec 5, 2016 at 12:05 PM, Sean Busbey wrote: > > > >> Hi folks! > >> > >> I'm planning to cut an RC for 1.2.5 at the end of this week. I don't > >> see any blockers in JIRA, so please let me know if there's something > >> that ought to stop a release. > >> > >> - > >> busbey > >> >
Re: Time for Apache HBase 1.2.5
I have not, thanks for the heads-up. HBASE-17069 is currently not marked blocker and has no assignee. If it's a blocker for 1.2.5, could the folks involved please correct this? On Mon, Dec 5, 2016 at 2:08 PM, Ted Yu wrote: > Sean: > Have you looked at HBASE-17069 ? > > Cheers > > On Mon, Dec 5, 2016 at 12:05 PM, Sean Busbey wrote: > >> Hi folks! >> >> I'm planning to cut an RC for 1.2.5 at the end of this week. I don't >> see any blockers in JIRA, so please let me know if there's something >> that ought to stop a release. >> >> - >> busbey >>
Re: Time for Apache HBase 1.2.5
Sean: Have you looked at HBASE-17069 ? Cheers On Mon, Dec 5, 2016 at 12:05 PM, Sean Busbey wrote: > Hi folks! > > I'm planning to cut an RC for 1.2.5 at the end of this week. I don't > see any blockers in JIRA, so please let me know if there's something > that ought to stop a release. > > - > busbey >
Time for Apache HBase 1.2.5
Hi folks! I'm planning to cut an RC for 1.2.5 at the end of this week. I don't see any blockers in JIRA, so please let me know if there's something that ought to stop a release. - busbey
[jira] [Resolved] (HBASE-16337) Removing peers seem to be leaving spare queues
[ https://issues.apache.org/jira/browse/HBASE-16337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling resolved HBASE-16337. --- Resolution: Duplicate Closing as a dupe, thanks for pointing it out. > Removing peers seem to be leaving spare queues > -- > > Key: HBASE-16337 > URL: https://issues.apache.org/jira/browse/HBASE-16337 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph > > I have been running IntegrationTestReplication repeatedly with the backported > Replication Table changes. Every other iteration of the test fails with, but > these queues should have been deleted when we removed the peers. I believe > this may be related to HBASE-16096, HBASE-16208, or HBASE-16081. > 16/08/02 08:36:07 ERROR util.AbstractHBaseTool: Error running command-line > tool > org.apache.hadoop.hbase.replication.ReplicationException: undeleted queue for > peerId: TestPeer, replicator: > hbase4124.ash2.facebook.com,16020,1470150251042, queueId: TestPeer > at > org.apache.hadoop.hbase.replication.ReplicationPeersZKImpl.checkQueuesDeleted(ReplicationPeersZKImpl.java:544) > at > org.apache.hadoop.hbase.replication.ReplicationPeersZKImpl.addPeer(ReplicationPeersZKImpl.java:127) > at > org.apache.hadoop.hbase.client.replication.ReplicationAdmin.addPeer(ReplicationAdmin.java:200) > at > org.apache.hadoop.hbase.test.IntegrationTestReplication$VerifyReplicationLoop.setupTablesAndReplication(IntegrationTestReplication.java:239) > at > org.apache.hadoop.hbase.test.IntegrationTestReplication$VerifyReplicationLoop.run(IntegrationTestReplication.java:325) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) > at > org.apache.hadoop.hbase.test.IntegrationTestReplication.runTestFromCommandLine(IntegrationTestReplication.java:418) > at > org.apache.hadoop.hbase.IntegrationTestBase.doWork(IntegrationTestBase.java:134) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:112) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) > at > org.apache.hadoop.hbase.test.IntegrationTestReplication.main(IntegrationTestReplication.java:424) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17259) Missing functionality to remove space quota
Josh Elser created HBASE-17259: -- Summary: Missing functionality to remove space quota Key: HBASE-17259 URL: https://issues.apache.org/jira/browse/HBASE-17259 Project: HBase Issue Type: Sub-task Reporter: Josh Elser Assignee: Josh Elser Fix For: 2.0.0 I'm noticing that while I have create and update APIs for quotas, I missed the remove functionality. Need to add public API for that and some tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-13078) IntegrationTestSendTraceRequests is a noop
[ https://issues.apache.org/jira/browse/HBASE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved HBASE-13078. Resolution: Fixed Fix Version/s: (was: 2.0.0) Best as I can tell, we landed the test fix on 1.0.x and 1.1.y here (no idea what the values of 'X' and 'Y' were when it first appeared anymore). HBASE-12938 was closed as "later" so the 0.98 branch changes can similarly be treated as "later". Closing this one to prevent later headache/confusion over what was done/needs to happen. > IntegrationTestSendTraceRequests is a noop > -- > > Key: HBASE-13078 > URL: https://issues.apache.org/jira/browse/HBASE-13078 > Project: HBase > Issue Type: Test > Components: integration tests >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Critical > Attachments: HBASE-13078-0.98-removal.patch, > HBASE-13078-0.98-v1.patch, HBASE-13078-v1.patch, HBASE-13078.patch > > > While pair-debugging with [~jeffreyz] on HBASE-13077, we noticed that > IntegrationTestSendTraceRequests doesn't actually assert anything. This test > should be converted to use a mini cluster, setup a POJOSpanReceiver, and then > verify the spans collected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Successful: HBase Generate Website
Build status: Successful
If successful, the website and docs have been generated. To update the live
site, follow the instructions below. If failed, skip to the bottom of this
email.
Use the following commands to download the patch and apply it to a clean branch
based on origin/asf-site. If you prefer to keep the hbase-site repo around
permanently, you can skip the clone step.
git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
cd hbase-site
wget -O-
https://builds.apache.org/job/hbase_generate_website/427/artifact/website.patch.zip
| funzip > 94302a3d26702b4ba07af76bf249298edf9118e4.patch
git fetch
git checkout -b asf-site-94302a3d26702b4ba07af76bf249298edf9118e4
origin/asf-site
git am --whitespace=fix 94302a3d26702b4ba07af76bf249298edf9118e4.patch
At this point, you can preview the changes by opening index.html or any of the
other HTML pages in your local
asf-site-94302a3d26702b4ba07af76bf249298edf9118e4 branch.
There are lots of spurious changes, such as timestamps and CSS styles in
tables, so a generic git diff is not very useful. To see a list of files that
have been added, deleted, renamed, changed type, or are otherwise interesting,
use the following command:
git diff --name-status --diff-filter=ADCRTXUB origin/asf-site
To see only files that had 100 or more lines changed:
git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'
When you are satisfied, publish your changes to origin/asf-site using these
commands:
git commit --allow-empty -m "Empty commit" # to work around a current ASF
INFRA bug
git push origin asf-site-94302a3d26702b4ba07af76bf249298edf9118e4:asf-site
git checkout asf-site
git branch -D asf-site-94302a3d26702b4ba07af76bf249298edf9118e4
Changes take a couple of minutes to be propagated. You can verify whether they
have been propagated by looking at the Last Published date at the bottom of
http://hbase.apache.org/. It should match the date in the index.html on the
asf-site branch in Git.
As a courtesy- reply-all to this email to let other committers know you pushed
the site.
If failed, see https://builds.apache.org/job/hbase_generate_website/427/console
[jira] [Created] (HBASE-17258) MultiByteBuff#getXXX() has issues
ramkrishna.s.vasudevan created HBASE-17258:
--
Summary: MultiByteBuff#getXXX() has issues
Key: HBASE-17258
URL: https://issues.apache.org/jira/browse/HBASE-17258
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Priority: Critical
MBB#getInt() - the relative getXXX() API has issues.
{code}
int remaining = this.curItem.remaining();
if (remaining >= Bytes.SIZEOF_INT) {
return this.curItem.getInt();
}
if (remaining == 0) {
if (items.length - 1 == this.curItemIndex) {
// means cur item is the last one and we wont be able to read a long.
Throw exception
throw new BufferUnderflowException();
}
this.curItemIndex++;
this.curItem = this.items[this.curItemIndex];
return this.curItem.getInt();
}
{code}
Now here if the curItem does not have anything remaining in it we just go to
the nextItem and from that we do a getInt. But we don't check if that item is
big enough to return an int. This may not happen in most of the real cases but
as an API it should handle that case. Since MBB are now used in the
RpcServer#response there could be some on demand BB created that are smaller in
sizes and it could lead to issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-17239) Add UnsafeByteOperations#wrap(ByteInput, int offset, int len) API
[ https://issues.apache.org/jira/browse/HBASE-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan resolved HBASE-17239. Resolution: Fixed Hadoop Flags: Reviewed > Add UnsafeByteOperations#wrap(ByteInput, int offset, int len) API > - > > Key: HBASE-17239 > URL: https://issues.apache.org/jira/browse/HBASE-17239 > Project: HBase > Issue Type: Improvement > Components: Protobufs >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-17239_V1.patch, HBASE-17239_V2.patch, > HBASE-17239_V3.patch > > > Instead of exposing the newInstance(ByteInput, boolean) in CIS we could just > add a UnsafeByteOperations#wrap(ByteInput, offset, len). And we could just > call that and do a #newcodedInput() over that. So internally we do return a > immutable version of the ByteInput only. This way we can avoid > CIS#newInstance(ByteInput) exposure and can keep it package private as done > in COS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17257) Add column-aliasing capability to hbase-client
Daniel Vimont created HBASE-17257: - Summary: Add column-aliasing capability to hbase-client Key: HBASE-17257 URL: https://issues.apache.org/jira/browse/HBASE-17257 Project: HBase Issue Type: New Feature Components: Client Affects Versions: 2.0.0 Reporter: Daniel Vimont Assignee: Daniel Vimont Column aliasing will provide the option for a 1, 2, or 4 byte alias value to be stored in each cell of an "alias enabled" column-family, in place of the full-length column-qualifier. Aliasing is intended to operate completely invisibly to the end-user developer, with absolutely no "awareness" of aliasing required to be coded into a front-end application. No new public hbase-client interfaces are to be introduced, and only a few new public methods should need to be added to existing interfaces, primarily to allow an administrator to designate that a new column-family is to be alias-enabled by setting its aliasSize attribute to 1, 2, or 4. To facilitate such functionality, new subclasses of HTable, BufferedMutatorImpl, and HTableMultiplexer are to be provided. The overriding methods of these new subclasses will invoke methods of the new AliasManager class to facilitate qualifier-to-alias conversions (for user-submitted Gets, Scans, and Mutations) and alias-to-qualifier conversions (for Results returned from HBase) for any Table that has one or more alias-enabled column families. All conversion logic will be encapsulated in the new AliasManager class, and all qualifier-to-alias mappings will be persisted in a new aliasMappingTable in a new, reserved namespace. An informal polling of HBase users at HBaseCon East and at the Strata/Hadoop-World conference in Sept. 2016 showed that Column Aliasing could be a popular enhancement to standard HBase functionality, due to the fact that full column-qualifiers are stored in each cell, and reducing this qualifier storage requirement down to 1, 2, or 4 bytes per cell could prove beneficial in terms of reduced storage and bandwidth needs. Aliasing is intended chiefly for column-families which are of the "narrow and tall" variety (i.e., that are designed to use relatively few distinct column-qualifiers throughout a large number of rows, throughout the lifespan of the column-family). A column-family that is set up with an alias-size of 1 byte can contain up to 255 unique column-qualifiers; a 2 byte alias-size allows for up to 65,535 unique column-qualifiers; and a 4 byte alias-size allows for up to 4,294,967,295 unique column-qualifiers. Fuller specifications will be entered into the comments section below. Note that it may well not be viable to add aliasing support in the new "async" classes that appear to be currently under development. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17256) Rpc handler monitoring will be removed when the task queue is full
Guangxu Cheng created HBASE-17256: - Summary: Rpc handler monitoring will be removed when the task queue is full Key: HBASE-17256 URL: https://issues.apache.org/jira/browse/HBASE-17256 Project: HBase Issue Type: Bug Affects Versions: 1.2.4, 0.98.23 Reporter: Guangxu Cheng The RPC handlers monitoring will displayed in the Web UI when the cluster has just started. As time goes on, RPC handlers disappeared . We have the RPC handlers listed as tasks and stored in CircularFifoBuffer. CircularFifoBuffer is a first in first out buffer with a fixed size that replaces its oldest element if full. When we refresh the page, completed tasks will be removed from CircularFifoBuffer. Not refresh the page for a long time, the oldest element (RPC handlers) will be replaced by new tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
