[jira] [Created] (HBASE-20803) add ZkAclReset tool documnet
Andy Lin created HBASE-20803: Summary: add ZkAclReset tool documnet Key: HBASE-20803 URL: https://issues.apache.org/jira/browse/HBASE-20803 Project: HBase Issue Type: Improvement Reporter: Andy Lin add document to describe ZkAclReset tool -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20804) Document for HBaseConfTool
Andy Lin created HBASE-20804: Summary: Document for HBaseConfTool Key: HBASE-20804 URL: https://issues.apache.org/jira/browse/HBASE-20804 Project: HBase Issue Type: Improvement Reporter: Andy Lin Add documentation for HBaseConfTool. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20805) Document for CreateSnapshot
Andy Lin created HBASE-20805: Summary: Document for CreateSnapshot Key: HBASE-20805 URL: https://issues.apache.org/jira/browse/HBASE-20805 Project: HBase Issue Type: Improvement Reporter: Andy Lin Add documentation for CreateSnapshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20806) Split style journal for flushes and compactions
Abhishek Singh Chouhan created HBASE-20806: -- Summary: Split style journal for flushes and compactions Key: HBASE-20806 URL: https://issues.apache.org/jira/browse/HBASE-20806 Project: HBase Issue Type: Improvement Reporter: Abhishek Singh Chouhan Assignee: Abhishek Singh Chouhan In 1.x we have split transaction journal that gives a clear picture of when various stages of splits took place. We should have a similar thing for flushes and compactions so as to have insights into time spent in various stages, which we can use to identify regressions that might creep up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20807) Complete the test and document for all public tools
Chia-Ping Tsai created HBASE-20807: -- Summary: Complete the test and document for all public tools Key: HBASE-20807 URL: https://issues.apache.org/jira/browse/HBASE-20807 Project: HBase Issue Type: Umbrella Components: tooling Reporter: Chia-Ping Tsai There are many tools having no tests and document. That may make the tools unstable and stale as time goes by. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20808) Wrong shutdown order between Chores and ChoreService
Reid Chan created HBASE-20808:
-
Summary: Wrong shutdown order between Chores and ChoreService
Key: HBASE-20808
URL: https://issues.apache.org/jira/browse/HBASE-20808
Project: HBase
Issue Type: Bug
Reporter: Reid Chan
When stopping master, {{ChoreService}}, which serves all the chores, is stopped
before canceling all running chores.
It should cancel all running chores, then shutdown {{ChoreService}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20809) Refactor ExpiredMobFileCleanerChore
Reid Chan created HBASE-20809:
-
Summary: Refactor ExpiredMobFileCleanerChore
Key: HBASE-20809
URL: https://issues.apache.org/jira/browse/HBASE-20809
Project: HBase
Issue Type: Improvement
Reporter: Reid Chan
Assignee: Reid Chan
There's already {{CleanerChore}} framework providing:
* multi-threads scan dir
* basic multi-threads deletion
* pluggable delegators to choose files to be deleted
* on-the-fly configuration
We can refactor {{ExpiredMobFileCleanerChore}} to make use of them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [RESULT][VOTE] Merge branch HBASE-19064 back to master
Merged back to master. Will keep an eye on the nightly build and flakey dashboard. Thanks. 2018-06-28 8:56 GMT+08:00 张铎(Duo Zhang) : > One week since we start the vote, and now we have 4 binding +1s, a 0, and > no -1s, so the vote passes. Let me close the vote. > > There are still small issues for branch HBASE-19064, will merge back to > master after we fix them all. > > Thanks all for voting. > > > 2018-06-26 18:20 GMT+08:00 Ashish Singhi : > >> SGTM. +1 >> >> Regards, >> Ashish >> >> On Tue, Jun 26, 2018 at 12:30 PM, 张铎(Duo Zhang) >> wrote: >> >> > Here is my +1. >> > >> > As the performance test shows that there is no performance downgrading >> if >> > we do not enable sync replication, and the feature basically works, I >> think >> > it is OK to merge it back to master branch. We will continue working on >> > polishing and optimizing it for the 3.0 release. >> > >> > 2018-06-26 14:52 GMT+08:00 OpenInx : >> > >> > > Hi guys >> > > >> > > I've tested the write performance on both master branch and >> HBASE-19064 >> > > branch. Here's the JIRA [1]. >> > > >> > > The conclusion(Pasted from the comment): >> > > The QPS & AVG latency are similar when comparing the master branch >> with >> > > async replication and HBASE-19064 with async replication. >> > > BTW the QPS of HBASE-19064 with sync replication dropped about 13%, we >> > will >> > > continue to optimize the sync replication in phrase#2 [2]. >> > > >> > > 1. https://issues.apache.org/jira/browse/HBASE-20751 >> > > 2. https://issues.apache.org/jira/browse/HBASE-20422 >> > > >> > > >> > > On Thu, Jun 21, 2018 at 9:57 PM, Guanghao Zhang >> > > wrote: >> > > >> > > > +1 >> > > > >> > > > 2018-06-21 18:26 GMT+08:00 mengli721014 on 163 dot com < >> > > > mengli721...@163.com >> > > > >: >> > > > >> > > > > 0 >> > > > > >> > > > > 使用AquaMail for Android发送 >> > > > > http://www.aqua-mail.com >> > > > > >> > > > > >> > > > > >> > > > > 在 2018年6月21日 下午4:21:26 "张铎(Duo Zhang)" >> 写道: >> > > > > >> > > > > In HBASE-19064 we aim to implement sync replication feature for >> > HBase. >> > > > You >> > > > >> can see the design doc for more details on how it works >> > > > >> >> > > > >> https://docs.google.com/document/d/193D3aOxD-muPIZuQfI4Zo3_ >> > > > >> qg6-Nepeu_kraYJVQkiE/edit# >> > > > >> >> > > > >> And now the feature basically works, we have tested it on real >> > > clusters, >> > > > >> and also provide the operational documentation in the ref guide. >> You >> > > can >> > > > >> see the 'Synchronous Replication' section in the ref guide of >> branch >> > > > >> HBASE-19064. >> > > > >> >> > > > >> There are known limitations for this feature, and we have >> > > > >> created HBASE-20422 to track them. >> > > > >> >> > > > >> Please vote: >> > > > >> [+1] Agree >> > > > >> [-1] Disagree >> > > > >> [0] Neutral >> > > > >> >> > > > >> Thanks. >> > > > >> >> > > > >> >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > >> > >
Re: [RESULT][VOTE] Merge branch HBASE-19064 back to master
Nice job, I will pay attention to the UT too.. On Thu, Jun 28, 2018 at 6:37 PM, 张铎(Duo Zhang) wrote: > Merged back to master. Will keep an eye on the nightly build and flakey > dashboard. > > Thanks. > > 2018-06-28 8:56 GMT+08:00 张铎(Duo Zhang) : > > > One week since we start the vote, and now we have 4 binding +1s, a 0, and > > no -1s, so the vote passes. Let me close the vote. > > > > There are still small issues for branch HBASE-19064, will merge back to > > master after we fix them all. > > > > Thanks all for voting. > > > > > > 2018-06-26 18:20 GMT+08:00 Ashish Singhi : > > > >> SGTM. +1 > >> > >> Regards, > >> Ashish > >> > >> On Tue, Jun 26, 2018 at 12:30 PM, 张铎(Duo Zhang) > >> wrote: > >> > >> > Here is my +1. > >> > > >> > As the performance test shows that there is no performance downgrading > >> if > >> > we do not enable sync replication, and the feature basically works, I > >> think > >> > it is OK to merge it back to master branch. We will continue working > on > >> > polishing and optimizing it for the 3.0 release. > >> > > >> > 2018-06-26 14:52 GMT+08:00 OpenInx : > >> > > >> > > Hi guys > >> > > > >> > > I've tested the write performance on both master branch and > >> HBASE-19064 > >> > > branch. Here's the JIRA [1]. > >> > > > >> > > The conclusion(Pasted from the comment): > >> > > The QPS & AVG latency are similar when comparing the master branch > >> with > >> > > async replication and HBASE-19064 with async replication. > >> > > BTW the QPS of HBASE-19064 with sync replication dropped about 13%, > we > >> > will > >> > > continue to optimize the sync replication in phrase#2 [2]. > >> > > > >> > > 1. https://issues.apache.org/jira/browse/HBASE-20751 > >> > > 2. https://issues.apache.org/jira/browse/HBASE-20422 > >> > > > >> > > > >> > > On Thu, Jun 21, 2018 at 9:57 PM, Guanghao Zhang > > >> > > wrote: > >> > > > >> > > > +1 > >> > > > > >> > > > 2018-06-21 18:26 GMT+08:00 mengli721014 on 163 dot com < > >> > > > mengli721...@163.com > >> > > > >: > >> > > > > >> > > > > 0 > >> > > > > > >> > > > > 使用AquaMail for Android发送 > >> > > > > http://www.aqua-mail.com > >> > > > > > >> > > > > > >> > > > > > >> > > > > 在 2018年6月21日 下午4:21:26 "张铎(Duo Zhang)" > >> 写道: > >> > > > > > >> > > > > In HBASE-19064 we aim to implement sync replication feature for > >> > HBase. > >> > > > You > >> > > > >> can see the design doc for more details on how it works > >> > > > >> > >> > > > >> https://docs.google.com/document/d/193D3aOxD-muPIZuQfI4Zo3_ > >> > > > >> qg6-Nepeu_kraYJVQkiE/edit# > >> > > > >> > >> > > > >> And now the feature basically works, we have tested it on real > >> > > clusters, > >> > > > >> and also provide the operational documentation in the ref > guide. > >> You > >> > > can > >> > > > >> see the 'Synchronous Replication' section in the ref guide of > >> branch > >> > > > >> HBASE-19064. > >> > > > >> > >> > > > >> There are known limitations for this feature, and we have > >> > > > >> created HBASE-20422 to track them. > >> > > > >> > >> > > > >> Please vote: > >> > > > >> [+1] Agree > >> > > > >> [-1] Disagree > >> > > > >> [0] Neutral > >> > > > >> > >> > > > >> Thanks. > >> > > > >> > >> > > > >> > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
[jira] [Created] (HBASE-20810) Include the procedure id in the exception message in HBaseAdmin for better debugging
Duo Zhang created HBASE-20810: - Summary: Include the procedure id in the exception message in HBaseAdmin for better debugging Key: HBASE-20810 URL: https://issues.apache.org/jira/browse/HBASE-20810 Project: HBase Issue Type: Improvement Components: Admin, proc-v2 Reporter: Duo Zhang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20811) HBase - Region Co-processors control Flow
sundaramoorthy M created HBASE-20811: Summary: HBase - Region Co-processors control Flow Key: HBASE-20811 URL: https://issues.apache.org/jira/browse/HBASE-20811 Project: HBase Issue Type: Brainstorming Components: Coprocessors Reporter: sundaramoorthy M In the HBase Region Co-processors the region prePut method is called before OR after the rowLock applied. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20812) Add defaults to Table Interface so implementors don't have to
stack created HBASE-20812: - Summary: Add defaults to Table Interface so implementors don't have to Key: HBASE-20812 URL: https://issues.apache.org/jira/browse/HBASE-20812 Project: HBase Issue Type: Bug Reporter: stack Lets add default implementaitons -- even if they are just throw NotImplementedException -- to our Table Interface now we are up on jdk8. Table implementations are how the likes of hbase-indexer modify hbase --via a publically supported API -- and I notice that the kafka proxy now goes the same route. Typically, these customizations are only interested in one or two methods of Table adding in their own implementations but they have to supply implementations for all Table methods in their override. Lets help them out by adding defaults (I had a patch but lost it...). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20813) Remove RPC quotas when the associated table is dropped off
Sakthi created HBASE-20813: -- Summary: Remove RPC quotas when the associated table is dropped off Key: HBASE-20813 URL: https://issues.apache.org/jira/browse/HBASE-20813 Project: HBase Issue Type: Sub-task Reporter: Sakthi Assignee: Sakthi -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20814) fix error prone assertion failure ignored warnings
Mike Drob created HBASE-20814: - Summary: fix error prone assertion failure ignored warnings Key: HBASE-20814 URL: https://issues.apache.org/jira/browse/HBASE-20814 Project: HBase Issue Type: Sub-task Components: build, test Reporter: Mike Drob Assignee: Mike Drob when we have assertion failures ignored, that likely means we're missing a test case, let's make sure our tests are actually running and covering what we think they are. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20815) In TestServerCrashProcedure collect and assert on submitted and failed counts for ServerCrashProcedure
Umesh Agashe created HBASE-20815: Summary: In TestServerCrashProcedure collect and assert on submitted and failed counts for ServerCrashProcedure Key: HBASE-20815 URL: https://issues.apache.org/jira/browse/HBASE-20815 Project: HBase Issue Type: Bug Components: amv2 Reporter: Umesh Agashe We need to collect and possibly assert on number of procedures submitted and failed for ServerCrashProcedures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20816) Run ITBLL for branch-2.1
Duo Zhang created HBASE-20816: - Summary: Run ITBLL for branch-2.1 Key: HBASE-20816 URL: https://issues.apache.org/jira/browse/HBASE-20816 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang Assignee: Duo Zhang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20817) Infinite loop when executing ReopenTableRegionsProcedure
Duo Zhang created HBASE-20817: - Summary: Infinite loop when executing ReopenTableRegionsProcedure Key: HBASE-20817 URL: https://issues.apache.org/jira/browse/HBASE-20817 Project: HBase Issue Type: Bug Components: Region Assignment Reporter: Duo Zhang Fix For: 3.0.0, 2.1.0, 2.0.2, 2.2.0 As discussed in HBASE-20792, it seems that a region's openSeqNum could remain the same after a sucessful reopen, which causes the RTRP loop infinitely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20818) Use TableDescriptor to replace HTableDescriptor in admin.rb
Xiaolin Ha created HBASE-20818: -- Summary: Use TableDescriptor to replace HTableDescriptor in admin.rb Key: HBASE-20818 URL: https://issues.apache.org/jira/browse/HBASE-20818 Project: HBase Issue Type: Improvement Components: shell Affects Versions: 2.0.0 Reporter: Xiaolin Ha Assignee: Xiaolin Ha HTableDescriptor is deprecated as of release 2.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20819) Use TableDescriptor to replace HTableDescriptor in admin.rb
Xiaolin Ha created HBASE-20819: -- Summary: Use TableDescriptor to replace HTableDescriptor in admin.rb Key: HBASE-20819 URL: https://issues.apache.org/jira/browse/HBASE-20819 Project: HBase Issue Type: Improvement Components: shell Affects Versions: 2.0.0 Reporter: Xiaolin Ha Assignee: Xiaolin Ha HTableDescriptor is deprecated as of release 2.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20820) Removing SpaceQuota from a namespace does not remove it completely
Nihal Jain created HBASE-20820:
--
Summary: Removing SpaceQuota from a namespace does not remove it
completely
Key: HBASE-20820
URL: https://issues.apache.org/jira/browse/HBASE-20820
Project: HBase
Issue Type: Bug
Reporter: Nihal Jain
Assignee: Nihal Jain
As demonstarted in
[HBASE-20662.master.002.patch|https://issues.apache.org/jira/secure/attachment/12927187/HBASE-20662.master.002.patch]
setting quota on a namespace and removing it does not remove the quota setting
from the tables in the namespace (which were added systematically due to
namespace quota settings).
*Relevant code:*
{code:java}
public void setQuotaAndThenRemove(final String namespace, SpaceViolationPolicy
policy)
throws Exception {
Put put = new Put(Bytes.toBytes("to_reject"));
put.addColumn(Bytes.toBytes(SpaceQuotaHelperForTests.F1), Bytes.toBytes("to"),
Bytes.toBytes("reject"));
// Set quota and do puts until we violate space policy
final TableName tn = writeUntilNSSpaceViolationAndVerifyViolation(namespace,
policy, put);
// Now, remove the quota
removeQuotaFromNamespace(namespace);
// Put some rows now: should not violate as quota settings removed
verifyNoViolation(policy, tn, put);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
