Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available
I think for a minor release, we do not expect a drop-in replacement, so changing the return value from void is fine? You do not need to change your code, just need to recompile it. Thanks. Stack 于2020年12月4日周五 下午1:58写道： > +0 for now until my question below gets an answer. > > Signature is good, hash is good. CHANGES and RELEASENOTES look good too. > Built from the src tgz. Artifact looks right when I untar it. > Started it in standalone mode. > UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time > statistics'... nice). > Loaded 10M rows w/ pe. Read them back out again. > I've been running unit tests over the last few days. There are flakies that > I've been trying > to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see > the last few as > cause to hold up the RC (NIghtlies on branch-2 have been pretty good of > late, see > > https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/ > ). > > Here is my question (Tosihrio?): > > Looking at API changes, this change looks problematic for a minor release: > > hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class > package org.apache.hadoop.hbase.client > [−] Table.mutateRow ( RowMutations rm ) *:* void 1 > > org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V > > ChangeEffect > 1 Return value type has been changed from *void* to *Result*. This method > has been removed because the return type is part of the method signature. A > client program may be interrupted by *NoSuchMethodError* exception. > > Done here > > commit 3775464981b473599c6d1bb24a7eea3badf0ed03 > Author: Toshihiro Suzuki > Date: Fri Nov 27 03:53:19 2020 +0900 > > HBASE-25242 Add Increment/Append support to RowMutations (#2711) > > Signed-off-by: Duo Zhang > Signed-off-by: Andrew Purtell > > The issue is called out as an incompatible change. I don't see discussion > on why this is ok in the PRs. Was I looking in right place? > > S > > On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell wrote: > > > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > > > > The VOTE will remain open for at least 72 hours. > > > > [ ] +1 Release this package as Apache hbase 2.4.0 > > [ ] -1 Do not release this package because ... > > > > The tag to be voted on is 2.4.0RC1: > > > > https://github.com/apache/hbase/tree/2.4.0RC1 > > > > The release files, including signatures, digests, as well as CHANGES.md > > and RELEASENOTES.md included in this RC can be found at: > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > > > > Customarily Maven artifacts would be available in a staging repository. > > Unfortunately I was forced to terminate the Maven deploy step after > > the upload ran for more than four hours and my build equipment > > needed to be relocated, with loss of network connectivity. This RC has > > been delayed long enough. A temporary Maven repository is not a > > requirement for a vote. I will retry Maven deploy tomorrow. I can > > promise the artifacts for this RC will be staged in Apache Nexus and > > ready for release well ahead of the earliest possible time this vote > > can complete. > > > > Artifacts were signed with the apurt...@apache.org key which can be > found > > in: > > > > https://dist.apache.org/repos/dist/release/hbase/KEYS > > > > The API compatibility report for this RC can be found at: > > > > > > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > > > > The changes are mostly added methods, which conform to the compatibility > > guidelines for a new minor release. There is one change to the public > > Region interface that alters the return type of a method. This is > > equivalent to a removal then addition and can be a binary compatibility > > problem. However to your RM's eye the change looks intentional and is > > part of an API improvement project, and a compatibility method is not > > possible here because Java doesn't consider return type when deciding if > > one method signature duplicates another. > > > > To learn more about Apache HBase, please see > > > > http://hbase.apache.org/ > > > > Thanks, > > Your HBase Release Manager > > >
Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available
+0 for now until my question below gets an answer. Signature is good, hash is good. CHANGES and RELEASENOTES look good too. Built from the src tgz. Artifact looks right when I untar it. Started it in standalone mode. UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time statistics'... nice). Loaded 10M rows w/ pe. Read them back out again. I've been running unit tests over the last few days. There are flakies that I've been trying to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see the last few as cause to hold up the RC (NIghtlies on branch-2 have been pretty good of late, see https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/ ). Here is my question (Tosihrio?): Looking at API changes, this change looks problematic for a minor release: hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class package org.apache.hadoop.hbase.client [−] Table.mutateRow ( RowMutations rm ) *:* void 1 org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V ChangeEffect 1 Return value type has been changed from *void* to *Result*. This method has been removed because the return type is part of the method signature. A client program may be interrupted by *NoSuchMethodError* exception. Done here commit 3775464981b473599c6d1bb24a7eea3badf0ed03 Author: Toshihiro Suzuki Date: Fri Nov 27 03:53:19 2020 +0900 HBASE-25242 Add Increment/Append support to RowMutations (#2711) Signed-off-by: Duo Zhang Signed-off-by: Andrew Purtell The issue is called out as an incompatible change. I don't see discussion on why this is ok in the PRs. Was I looking in right place? S On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell wrote: > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > > The VOTE will remain open for at least 72 hours. > > [ ] +1 Release this package as Apache hbase 2.4.0 > [ ] -1 Do not release this package because ... > > The tag to be voted on is 2.4.0RC1: > > https://github.com/apache/hbase/tree/2.4.0RC1 > > The release files, including signatures, digests, as well as CHANGES.md > and RELEASENOTES.md included in this RC can be found at: > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > > Customarily Maven artifacts would be available in a staging repository. > Unfortunately I was forced to terminate the Maven deploy step after > the upload ran for more than four hours and my build equipment > needed to be relocated, with loss of network connectivity. This RC has > been delayed long enough. A temporary Maven repository is not a > requirement for a vote. I will retry Maven deploy tomorrow. I can > promise the artifacts for this RC will be staged in Apache Nexus and > ready for release well ahead of the earliest possible time this vote > can complete. > > Artifacts were signed with the apurt...@apache.org key which can be found > in: > > https://dist.apache.org/repos/dist/release/hbase/KEYS > > The API compatibility report for this RC can be found at: > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > > The changes are mostly added methods, which conform to the compatibility > guidelines for a new minor release. There is one change to the public > Region interface that alters the return type of a method. This is > equivalent to a removal then addition and can be a binary compatibility > problem. However to your RM's eye the change looks intentional and is > part of an API improvement project, and a compatibility method is not > possible here because Java doesn't consider return type when deciding if > one method signature duplicates another. > > To learn more about Apache HBase, please see > > http://hbase.apache.org/ > > Thanks, > Your HBase Release Manager >
[jira] [Created] (HBASE-25358) meta replica regions are assigned to
Huaxiang Sun created HBASE-25358: Summary: meta replica regions are assigned to Key: HBASE-25358 URL: https://issues.apache.org/jira/browse/HBASE-25358 Project: HBase Issue Type: Bug Components: read replicas Reporter: Huaxiang Sun -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25357) allow specifying binary row key range to pre-split regions
Yubao Liu created HBASE-25357: - Summary: allow specifying binary row key range to pre-split regions Key: HBASE-25357 URL: https://issues.apache.org/jira/browse/HBASE-25357 Project: HBase Issue Type: Improvement Components: spark Reporter: Yubao Liu Currently, spark hbase connector use `String` to specify regionStart and regionEnd, but we often have serialized binary row key, I made a little patch at [https://github.com/apache/hbase-connectors/pull/72/files] to always treat the `String` in ISO_8859_1, so we can put raw bytes into the String object and get it unchanged. This has a drawback, if your row key is really UTF-8 strings, you should convert it to UTF-8 encoded bytes and then encapsulate it in ISO_8859_1 string. This is a limitation of Spark option interface which allows only string to string map. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24966) The methods in AsyncTableRegionLocator should not throw IOException directly
[ https://issues.apache.org/jira/browse/HBASE-24966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-24966. --- Resolution: Fixed Merged to master. Thanks [~nicholasjiang] for contributing. > The methods in AsyncTableRegionLocator should not throw IOException directly > > > Key: HBASE-24966 > URL: https://issues.apache.org/jira/browse/HBASE-24966 > Project: HBase > Issue Type: Bug > Components: API, Client >Reporter: Duo Zhang >Assignee: Nicholas Jiang >Priority: Major > Fix For: 3.0.0-alpha-1 > > > This is an incompatible change as we changed the method signature. > But anyway this is a mistake so we should fix it... -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available
Thanks Andrew. Running itbll with meta replica load balance mode now, will report back tomorrow. Huaxiang On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell wrote: > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > > The VOTE will remain open for at least 72 hours. > > [ ] +1 Release this package as Apache hbase 2.4.0 > [ ] -1 Do not release this package because ... > > The tag to be voted on is 2.4.0RC1: > > https://github.com/apache/hbase/tree/2.4.0RC1 > > The release files, including signatures, digests, as well as CHANGES.md > and RELEASENOTES.md included in this RC can be found at: > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > > Customarily Maven artifacts would be available in a staging repository. > Unfortunately I was forced to terminate the Maven deploy step after > the upload ran for more than four hours and my build equipment > needed to be relocated, with loss of network connectivity. This RC has > been delayed long enough. A temporary Maven repository is not a > requirement for a vote. I will retry Maven deploy tomorrow. I can > promise the artifacts for this RC will be staged in Apache Nexus and > ready for release well ahead of the earliest possible time this vote > can complete. > > Artifacts were signed with the apurt...@apache.org key which can be found > in: > > https://dist.apache.org/repos/dist/release/hbase/KEYS > > The API compatibility report for this RC can be found at: > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > > The changes are mostly added methods, which conform to the compatibility > guidelines for a new minor release. There is one change to the public > Region interface that alters the return type of a method. This is > equivalent to a removal then addition and can be a binary compatibility > problem. However to your RM's eye the change looks intentional and is > part of an API improvement project, and a compatibility method is not > possible here because Java doesn't consider return type when deciding if > one method signature duplicates another. > > To learn more about Apache HBase, please see > > http://hbase.apache.org/ > > Thanks, > Your HBase Release Manager >
[VOTE] First release candidate for HBase 2.4.0 (RC1) is available
Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 The VOTE will remain open for at least 72 hours. [ ] +1 Release this package as Apache hbase 2.4.0 [ ] -1 Do not release this package because ... The tag to be voted on is 2.4.0RC1: https://github.com/apache/hbase/tree/2.4.0RC1 The release files, including signatures, digests, as well as CHANGES.md and RELEASENOTES.md included in this RC can be found at: https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ Customarily Maven artifacts would be available in a staging repository. Unfortunately I was forced to terminate the Maven deploy step after the upload ran for more than four hours and my build equipment needed to be relocated, with loss of network connectivity. This RC has been delayed long enough. A temporary Maven repository is not a requirement for a vote. I will retry Maven deploy tomorrow. I can promise the artifacts for this RC will be staged in Apache Nexus and ready for release well ahead of the earliest possible time this vote can complete. Artifacts were signed with the apurt...@apache.org key which can be found in: https://dist.apache.org/repos/dist/release/hbase/KEYS The API compatibility report for this RC can be found at: https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html The changes are mostly added methods, which conform to the compatibility guidelines for a new minor release. There is one change to the public Region interface that alters the return type of a method. This is equivalent to a removal then addition and can be a binary compatibility problem. However to your RM's eye the change looks intentional and is part of an API improvement project, and a compatibility method is not possible here because Java doesn't consider return type when deciding if one method signature duplicates another. To learn more about Apache HBase, please see http://hbase.apache.org/ Thanks, Your HBase Release Manager
[jira] [Resolved] (HBASE-21591) Support ability to have host based permissions
[
https://issues.apache.org/jira/browse/HBASE-21591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clay B. resolved HBASE-21591.
-
Resolution: Won't Fix
I do not have the intention to work on this further as I have been informed one
can achieve this using Apache Ranger in front of HBase.
> Support ability to have host based permissions
> --
>
> Key: HBASE-21591
> URL: https://issues.apache.org/jira/browse/HBASE-21591
> Project: HBase
> Issue Type: Improvement
> Components: security
>Reporter: Clay B.
>Assignee: Clay B.
>Priority: Trivial
>
> Today, one can put in an ACL rule where a user is not permitted to read data
> but can insert data (e.g. {{grant 'user', 'table', 'W'}}). However, one can
> not implement HBase as a "drop-box" for data where by in a secure network,
> one can read and write data but outside that secure network one can only
> write data; and I do not believe this is possible with custom access
> controllers, unless one "wraps" HBase; e.g. with the HBase REST server.
> I have been pushing for this model (e.g. [Of Data Dropboxes and Data
> Gloveboxes|https://thestrangeloop.com/2018/of-data-dropboxes-and-data-gloveboxes.html]
> or
> [slides|http://clayb.net/presentations/Of%20Data%20Dropboxes%20and%20Data%20Gloveboxes.pdf])
> in a number of technologies for some data compartmentalization initiatives.
> I propose passing the requester's host information through the HBase
> authentication stack so that the ACL model in HBase can work akin to the SQL
> semantics of {{user@host}} or {{user@}}.The expected impact would
> be to HBase private interfaces only, so far in POC'ing it seems the following
> would be impacted:
> Access Control Classes/ACL Table Management:
> * AccessControlUtil
> * UserPermission
> * AccessChecker
> * AccessControlFilter
> * AccessController
> * AuthResult
> * TableAuthManager
> * AccessControl.proto
> Co-Processor APIs for Checking Authentication:
> * CoprocessorHost
> * ObserverContext
> * ObserverContextImpl
> * RSRpcServices
> * RSGroupAdminEndpoint
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: 2.4.0RC0 is DOA, starting 2.4.0RC1
The bits have been uploading via SVN commit to staging and Maven deploy for a couple of hours now. Rate is about 1MB/minute. The bottleneck appears to be on the Apache side. It will take another few hours to complete, then I will start the VOTE. On Thu, Dec 3, 2020 at 9:31 AM Andrew Purtell wrote: > Last night we had a revert of HBASE-25246. I have to start over. > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Created] (HBASE-25356) shell command major_compact misbehave for hbase:meta
Huaxiang Sun created HBASE-25356: Summary: shell command major_compact misbehave for hbase:meta Key: HBASE-25356 URL: https://issues.apache.org/jira/browse/HBASE-25356 Project: HBase Issue Type: Bug Components: shell Affects Versions: 1.6.0, 2.4.0 Reporter: Huaxiang Sun Assignee: Huaxiang Sun I was running shell command to major compact meta table. The implementation is wrong because it tries to search the meta table with meta table name. This also results in an unnecessary scan of meta table. majorCompactRegion() is calling getRegion() which basically scan meta table itself. This command is being used by operator quite often, we need to correct it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
2.4.0RC0 is DOA, starting 2.4.0RC1
Last night we had a revert of HBASE-25246. I have to start over. -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Reopened] (HBASE-25246) Backup/Restore hbase cell tags.
[ https://issues.apache.org/jira/browse/HBASE-25246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani reopened HBASE-25246: -- > Backup/Restore hbase cell tags. > --- > > Key: HBASE-25246 > URL: https://issues.apache.org/jira/browse/HBASE-25246 > Project: HBase > Issue Type: Improvement > Components: backuprestore >Reporter: Rushabh Shah >Assignee: Rushabh Shah >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.0, 2.2.7, 2.3.4 > > > In PHOENIX-6213 we are planning to add cell tags for Delete mutations. After > having a discussion with hbase community via dev mailing thread, it was > decided that we will pass the tags via an attribute in Mutation object and > persist them to hbase via phoenix co-processor. The intention of PHOENIX-6213 > is to store metadata in Delete marker so that while running Restore tool we > can selectively restore certain Delete markers and ignore others. For that to > happen we need to persist these tags in Backup and retrieve them in Restore > MR jobs (Import/Export tool). > Currently we don't persist the tags in Backup. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [ANNOUNCE] New HBase committer Xin Sun
Congratulations and Welcome Xin Sun !! On Thu, 3 Dec 2020 at 2:43 PM, Guanghao Zhang wrote: > Folks, > > On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun has > accepted the PMC's invitation to become a committer on the project. > > We appreciate all of the great contributions Xin Sun has made to the > community thus far and we look forward to his continued involvement. > > Allow me to be the first to congratulate Xin Sun on his new role! > > Thanks. >
Re: [ANNOUNCE] New HBase committer Yulin Niu
Congratulations and Welcome Yulin Niu !! On Thu, 3 Dec 2020 at 2:42 PM, Guanghao Zhang wrote: > Folks, > > On behalf of the Apache HBase PMC I am pleased to announce that Yulin Niu > has accepted the PMC's invitation to become a committer on the project. > > We appreciate all of the great contributions Yulin has made to the > community thus far and we look forward to his continued involvement. > > Allow me to be the first to congratulate Yulin on his new role! > > Thanks. >
[jira] [Resolved] (HBASE-25355) [Documentation] Fix spelling error
[
https://issues.apache.org/jira/browse/HBASE-25355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-25355.
---
Fix Version/s: 2.4.0
3.0.0-alpha-1
Hadoop Flags: Reviewed
Resolution: Fixed
Pushed to master and branch-2.
Thanks [~tangtianhang] for contributing.
> [Documentation] Fix spelling error
> ---
>
> Key: HBASE-25355
> URL: https://issues.apache.org/jira/browse/HBASE-25355
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: tianhang tang
>Assignee: tianhang tang
>Priority: Trivial
> Fix For: 3.0.0-alpha-1, 2.4.0
>
>
> [164.8.1. Understanding the
> output|https://hbase.apache.org/book.html#_understanding_the_output]
> {quote}This could also happen if replication is manually paused (via hbase
> shell disable_peer command, for example), but date keeps getting ingested in
> the source cluster tables.{quote}
> It should be:
> "but *_data_* keeps getting ingested in the source cluster tables."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
RE: [ANNOUNCE] New HBase committer Xin Sun
Congratulations & welcome Xin Sun!! Regards, Pankaj -Original Message- From: Guanghao Zhang [mailto:zghao...@gmail.com] Sent: Thursday, December 3, 2020 2:43 PM To: HBase Dev List ; Hbase-User Subject: [ANNOUNCE] New HBase committer Xin Sun Folks, On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun has accepted the PMC's invitation to become a committer on the project. We appreciate all of the great contributions Xin Sun has made to the community thus far and we look forward to his continued involvement. Allow me to be the first to congratulate Xin Sun on his new role! Thanks.
RE: [ANNOUNCE] New HBase committer Yulin Niu
Congratulations & welcome Yulin!! Regards, Pankaj -Original Message- From: Guanghao Zhang [mailto:zghao...@gmail.com] Sent: Thursday, December 3, 2020 2:42 PM To: HBase Dev List ; Hbase-User Subject: [ANNOUNCE] New HBase committer Yulin Niu Folks, On behalf of the Apache HBase PMC I am pleased to announce that Yulin Niu has accepted the PMC's invitation to become a committer on the project. We appreciate all of the great contributions Yulin has made to the community thus far and we look forward to his continued involvement. Allow me to be the first to congratulate Yulin on his new role! Thanks.
[jira] [Created] (HBASE-25355) [Documentation] Fix spelling error
tianhang tang created HBASE-25355:
-
Summary: [Documentation] Fix spelling error
Key: HBASE-25355
URL: https://issues.apache.org/jira/browse/HBASE-25355
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: tianhang tang
Assignee: tianhang tang
[164.8.1. Understanding the
output|https://hbase.apache.org/book.html#_understanding_the_output]
{quote}This could also happen if replication is manually paused (via hbase
shell disable_peer command, for example), but date keeps getting ingested in
the source cluster tables.{quote}
It should be:
"but *_data_* keeps getting ingested in the source cluster tables."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [ANNOUNCE] New HBase committer Xin Sun
Congratulations! Wellington Chevreuil 于2020年12月3日周四 下午5:38写道： > Congratulations and welcome! > > Em qui., 3 de dez. de 2020 às 09:13, Guanghao Zhang > escreveu: > > > Folks, > > > > On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun > has > > accepted the PMC's invitation to become a committer on the project. > > > > We appreciate all of the great contributions Xin Sun has made to the > > community thus far and we look forward to his continued involvement. > > > > Allow me to be the first to congratulate Xin Sun on his new role! > > > > Thanks. > > >
Re: [ANNOUNCE] New HBase committer Yulin Niu
Congratulations! Guanghao Zhang 于2020年12月3日周四 下午5:11写道： > Folks, > > On behalf of the Apache HBase PMC I am pleased to announce that Yulin Niu > has accepted the PMC's invitation to become a committer on the project. > > We appreciate all of the great contributions Yulin has made to the > community thus far and we look forward to his continued involvement. > > Allow me to be the first to congratulate Yulin on his new role! > > Thanks. >
Re: [ANNOUNCE] New HBase committer Xin Sun
Congratulations and welcome! Em qui., 3 de dez. de 2020 às 09:13, Guanghao Zhang escreveu: > Folks, > > On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun has > accepted the PMC's invitation to become a committer on the project. > > We appreciate all of the great contributions Xin Sun has made to the > community thus far and we look forward to his continued involvement. > > Allow me to be the first to congratulate Xin Sun on his new role! > > Thanks. >
[jira] [Resolved] (HBASE-25230) Embedded zookeeper server not clean up the old data
[
https://issues.apache.org/jira/browse/HBASE-25230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-25230.
--
Fix Version/s: 2.4.1
2.5.0
2.3.4
2.2.7
1.7.0
3.0.0-alpha-1
Hadoop Flags: Reviewed
Resolution: Fixed
Thanks for the contribution [~lgoswami].
> Embedded zookeeper server not clean up the old data
> ---
>
> Key: HBASE-25230
> URL: https://issues.apache.org/jira/browse/HBASE-25230
> Project: HBase
> Issue Type: Bug
> Components: Zookeeper
>Reporter: Rural Hunter
>Assignee: Laxman Goswami
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 1.7.0, 2.2.7, 2.3.4, 2.5.0, 2.4.1
>
>
> The size of zookeeper data dir keeps increasing. I checked the source code
> and found the zookeeper data cleanup manager is not started by hbase. The
> standalone zookeeper server runs the data cleanup manager but hbase does not.
> I suggest add the code below at the beginning of
> org.apache.hadoop.hbase.zookeeper.HQuorumPeer.runZKServer():
> {code:java}
> // Start and schedule the the purge task
> DatadirCleanupManager purgeMgr=new DatadirCleanupManager(
> zkConfig.getDataDir(),
> zkConfig.getDataLogDir(),
> zkConfig.getSnapRetainCount(),
> zkConfig.getPurgeInterval());
> purgeMgr.start();
> {code}
> I've been running this code in my hbase cluster for quite a long time without
> problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[ANNOUNCE] New HBase committer Xin Sun
Folks, On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun has accepted the PMC's invitation to become a committer on the project. We appreciate all of the great contributions Xin Sun has made to the community thus far and we look forward to his continued involvement. Allow me to be the first to congratulate Xin Sun on his new role! Thanks.
[ANNOUNCE] New HBase committer Yulin Niu
Folks, On behalf of the Apache HBase PMC I am pleased to announce that Yulin Niu has accepted the PMC's invitation to become a committer on the project. We appreciate all of the great contributions Yulin has made to the community thus far and we look forward to his continued involvement. Allow me to be the first to congratulate Yulin on his new role! Thanks.
