[jira] [Created] (HBASE-26980) Update javadoc of BucketCache.java
Xuesen Liang created HBASE-26980: Summary: Update javadoc of BucketCache.java Key: HBASE-26980 URL: https://issues.apache.org/jira/browse/HBASE-26980 Project: HBase Issue Type: Improvement Reporter: Xuesen Liang Assignee: Xuesen Liang The feature of on-heap Bucket cache was removed by [HBASE-19187|https://issues.apache.org/jira/browse/HBASE-19187]. We should update its javadoc which now is inaccurate and confusing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26979) StoreFileListFile logs frequent stacktraces at INFO level
Andrew Kyle Purtell created HBASE-26979:
---
Summary: StoreFileListFile logs frequent stacktraces at INFO level
Key: HBASE-26979
URL: https://issues.apache.org/jira/browse/HBASE-26979
Project: HBase
Issue Type: Bug
Affects Versions: 2.5.0
Reporter: Andrew Kyle Purtell
Assignee: Andrew Kyle Purtell
Fix For: 2.5.0, 3.0.0-alpha-3
In StoreFileTrackFile we have:
{code}
} catch (EOFException e) {
// this is normal case, so use info and do not log stacktrace
LOG.info("Failed to load track file {}: {}", trackFiles[i],
e.toString());
}
{code}
except that we see frequent stacktraces at INFO level from StoreFileListFile
and this appear to be the culprit.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (HBASE-26951) HMaster should exit gracefully, when stopped via hbase-daemon.sh
[ https://issues.apache.org/jira/browse/HBASE-26951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li resolved HBASE-26951. --- Hadoop Flags: Reviewed Resolution: Fixed Fixed in master branch via ba713ac Thanks [~heliangjun] for the contribution and thanks [~zhangduo] for review. > HMaster should exit gracefully, when stopped via hbase-daemon.sh > > > Key: HBASE-26951 > URL: https://issues.apache.org/jira/browse/HBASE-26951 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 3.0.0-alpha-2 >Reporter: LiangJun He >Assignee: LiangJun He >Priority: Critical > Fix For: 3.0.0-alpha-3 > > > Since ShutdownHook is not registered at startup, when HMaster is stopped > through hbase-daemon.sh, HMaster cannot exit gracefully, the threads and > services of HMaster cannot be closed normally, and the master local region > also cannot be closed normally, which may lead to some inexplicable problems. -- This message was sent by Atlassian Jira (v8.20.7#820007)
HBase Quarterly report Jan-Mar 2022
Hi all, HBase submits a report to the ASF board once a quarter, to inform the board about project health. I'm sending the report to the user@ and dev@ mailing lists because you are the project, and for transparency. If you have any questions about the report or the running of the project, you can post them to any PMC member or committer, or send an email to priv...@hbase.apache.org , which every PMC member subscribes to. ## Description: Apache HBase is an open-source, distributed, versioned, non-relational database. Apache HBase gives you low latency random access to billions of rows with millions of columns atop non-specialized hardware. hbase-thirdparty is a set of internal artifacts used by the project to mitigate the impact of our dependency choices on the wider ecosystem. hbase-connectors is a collection of integration points with other projects. The initial release includes artifacts for use with Apache Kafka and Apache Spark. hbase-filesystem contains HBase project-specific implementations of the Apache Hadoop FileSystem API. It is currently experimental and internal to the project. hbase-operator-tools is a collection of tools for HBase operators. Now it is mainly for hosting HBCK2. hbase-native-client is a client library in C/C++, in its early days. ## Issues: The ci-hbase jenkins was broken for almost 3 days during 2.20 - 2.23, finally the infra team recovered by restoring a backup on 2.17. But looking at the status.apache.org page, there is no record about this outage. So we wonder whether the current availabilty metrics is enough to reflect the real 'availability' of our system. ## Membership Data: Apache HBase was founded 2010-04-21 (12 years ago) There are currently 98 committers and 56 PMC members in this project. The Committer-to-PMC ratio is 7:4. Community changes, past quarter: - No new PMC members. Last addition was Bharath Vissapragada on 2021-07-30. - Chenglei was added as committer on 2022-02-15 - Yutong Xiao was added as committer on 2022-02-23 ## Project Activity: Recent releases: 2.4.11 was released on 2022-03-18. hbase-thirdparty-4.1.0 was released on 2022-03-11. 2.4.10 was released on 2022-03-04. We decided to use spotless to auto format our code to make our contributor easier to fix the checkstyle issues when submitting PR. https://lists.apache.org/thread/5r1kgmqkkgch8zx6wmhjvlv1kjdy9h59 We talked about whether to EOM branch-1, no final decision has been made but we agreed to make a 1.7.2 release and checked again on 2022.7.21. https://lists.apache.org/thread/8qy2lqtdwzc10tqnfdhrqvo35z6vkrvk We talked about removing JDK8 support on master branch and finally we found a way to compile with JDK11 but still maintain compatilibity with JDK8 https://lists.apache.org/thread/w5lrxkhswlonj09xf9hcwgvck3nsjdfx https://issues.apache.org/jira/browse/HBASE-25465 We talked about which logging framework to use. The candidates were reload4j, logback and log4j2. After some important improvements in log4j2, finally we migrated all the new release lines to use log4j2. We still need to test the log4j1 compability in the future. https://lists.apache.org/thread/kfmjg6zmvdjqcwolj0oh634nzv42y806 https://lists.apache.org/thread/gvfb3jkg6t11cyds4jmpo7lrswmx28w3 https://issues.apache.org/jira/browse/HBASE-26802 https://issues.apache.org/jira/browse/LOG4J2-3341 https://issues.apache.org/jira/browse/LOG4J2-3394 We talked about how to better maintain our ref guide as we kept removing the information for EOM release lines from the ref guide but the per release line ref guide is not well maintained. The final decision is to only maintain the ref guide on master branch and include all the information in it, include the EOM release lines. https://lists.apache.org/thread/bd6x1gnpgh0p3n4c2bnr1m4qpp7xxclc https://issues.apache.org/jira/browse/HBASE-26930 ## Community Health: - Mailing list activity: dev@hbase.apache.org: 953 subscribers(955 in the previous quarter) 897 emails sent to list(897 in the previous quarter) u...@hbase.apache.org: 2001 subscribers(2010 in the previous quarter) 88 emails sent to list(88 in the previous quarter) user...@hbase.apache.org 74 subscribers(72 in the previous quarter) 10 emails sent to list(10 in the previous quarter) - JIRA activity: 278 issues opened in JIRA, past quarter (-11% decrease) 247 issues closed in JIRA, past quarter (-10% decrease) - Commit activity: 738 commits in the past quarter (-21% increase) 49 code contributors in the past quarter (-23% increase) - GitHub PR activity: 325 PRs opened on GitHub, past quarter (2% increase) 313 PRs closed on GitHub, past quarter (no change) The community is overall health. The 2.5.0 release is delayed because we want to put more features to it, like better cloud object storage support, and also because we spent sometime to decide which logging framework to use, reload4j, logback or log4j2.And all these problems have been solved so we can expect the 2.5.0 release to come out soon.
Re: [DISCUSS] Use spotless to auto format pom and java code
+1 for Duo's bump here -- let's bring this home! On Tue, Apr 26, 2022 at 4:08 PM 张铎(Duo Zhang) wrote: > Just a reminder that some of us have almost reached a consensus on the > final formatter config file. > > PTAL about the discussion and also the final style in this PR > https://github.com/apache/hbase/pull/4312 > > We have also talked about whether we should just use some well known styles > such as google java format. > > So please reply here if you have any thoughts on this, i.e, which style do > you prefer more, the current eclipse formatter, or google java format, or > some other styles. > > Thanks a lot! > > 张铎(Duo Zhang) 于2022年4月13日周三 07:48写道： > > > Some heads up, the current state on the big reformat can be reviewed here > > > > https://github.com/apache/hbase/pull/4312 > > > > Shout if you have any questions about the formatter, we could try to > tweak > > the eclipse formatter to see if it could work as expected. > > > > Thanks. > > > > Andrew Purtell 于2022年4月3日周日 02:34写道： > > > >> I think we have consensus to move forward with application of the PRs, > so > >> let's fine tune the formatting configuration, and then regenerate and > >> apply > >> them. > >> > >> > >> On Thu, Mar 31, 2022 at 11:03 PM 张铎(Duo Zhang) > >> wrote: > >> > >> > FWIW, you could do a 'git reset --hard' to the commit before the big > >> > reformat and do a 'git blame' again on command line. > >> > > >> > Nick Dimiduk 于2022年4月1日周五 13:58写道： > >> > > >> > > I noticed that GitHub’s blame UI has a “show before this commit” > >> feature, > >> > > which allowed me to look at the blame info before the reformat was > >> > applied. > >> > > I assume the same is possible on the command line. > >> > > > >> > > On Fri, Apr 1, 2022 at 04:06 张铎(Duo Zhang) > >> > wrote: > >> > > > >> > > > +1 > >> > > > > >> > > > Andrew Purtell 于2022年4月1日周五 06:18写道： > >> > > > > >> > > > > Now that I understand what 'ratchetFrom' in the plugin > >> configuration > >> > > was > >> > > > > doing, I have removed it, and resubmitted the PRs. They are all > >> > > > ridiculous > >> > > > > and expected. Just about every file in the source is touched. On > >> > master > >> > > > > branch 4679 files are modified out of 5507 (excluding .git/). > >> There > >> > are > >> > > > > similar results for other branches. > >> > > > > > >> > > > > I think we should first spot check the PRs to determine if > >> spotless > >> > > > > configuration should be fine tuned. Then once it is acceptable > the > >> > PRs > >> > > > can > >> > > > > be updated with a re-application. Merging them applies a one > shot > >> > > > > reformatting to all live branches. This is desirable so that > going > >> > > > forward > >> > > > > it will be easier for reviewers and committers to manage PRs and > >> > > commits > >> > > > to > >> > > > > multiple branches. Put another way, if we don't do it, merge > >> > conflicts > >> > > > are > >> > > > > more likely. > >> > > > > > >> > > > > By adopting spotless and a particular configuration as our > coding > >> > > > standard, > >> > > > > and by opting in to automatic application of that policy as part > >> of > >> > our > >> > > > > patch submission process, we also agree that a discontinuity in > >> > history > >> > > > > (i.e. 'git blame' will be less useful prior to the application > of > >> the > >> > > > > reformatting than afterward) is an acceptable trade off. If this > >> is > >> > > true > >> > > > we > >> > > > > can move forward. If not it needs more discussion. > >> > > > > > >> > > > > > >> > > > > On Mon, Mar 28, 2022 at 7:08 PM Andrew Purtell < > >> apurt...@apache.org> > >> > > > > wrote: > >> > > > > > >> > > > > > Yes, I figure we should run spotless on all live branch-2x > >> branches > >> > > to > >> > > > > get > >> > > > > > a baseline for future contributions and backports. > >> > > > > > > >> > > > > > On Mon, Mar 28, 2022 at 6:50 PM 张铎(Duo Zhang) < > >> > palomino...@gmail.com > >> > > > > >> > > > > > wrote: > >> > > > > > > >> > > > > >> I’m natural on this. We could remove the ratchetFrom config > and > >> > do a > >> > > > > full > >> > > > > >> reformat on all branches. The problem is git blame will be > >> > useless… > >> > > > > >> > >> > > > > >> But anyway, if the file has been touched later, git blame > will > >> be > >> > > > broken > >> > > > > >> too. > >> > > > > >> > >> > > > > >> I saw Andrew has already opened a PR. Let’s get it done. > >> > > > > >> > >> > > > > >> Thanks. > >> > > > > >> > >> > > > > >> Bryan Beaudreault >> .invalid>于2022年3月29日 > >> > > > > >> 周二00:55写道： > >> > > > > >> > >> > > > > >> > Thanks for your work here Duo! > >> > > > > >> > > >> > > > > >> > What should be our convention on committing unrelated > >> formatting > >> > > > > changes > >> > > > > >> > due to spotless? For example, I have a PR > >> > > > > >> > https://github.com/apache/hbase/pull/4180 open. I rebased > >> it on > >> > > > > latest > >> > > > > >> > master to pull in spotless and ran `mvn spotless:a
Re: [ANNOUNCE] New HBase committer Bryan Beaudreault
Congrats Bryan! On 4/9/22 7:44 AM, 张铎(Duo Zhang) wrote: On behalf of the Apache HBase PMC, I am pleased to announce that Bryan Beaudreault(bbeaudreault) has accepted the PMC's invitation to become a committer on the project. We appreciate all of Bryan's generous contributions thus far and look forward to his continued involvement. Congratulations and welcome, Bryan Beaudreault! 我很高兴代表 Apache HBase PMC 宣布 Bryan Beaudreault 已接受我们的邀请，成为 Apache HBase 项目的 Committer。感谢 Bryan Beaudreault 一直以来为 HBase 项目做出的贡献，并期待他在未来继续承担更多的责任。 欢迎 Bryan Beaudreault！
Re: [DISCUSS] Use spotless to auto format pom and java code
Just a reminder that some of us have almost reached a consensus on the final formatter config file. PTAL about the discussion and also the final style in this PR https://github.com/apache/hbase/pull/4312 We have also talked about whether we should just use some well known styles such as google java format. So please reply here if you have any thoughts on this, i.e, which style do you prefer more, the current eclipse formatter, or google java format, or some other styles. Thanks a lot! 张铎(Duo Zhang) 于2022年4月13日周三 07:48写道： > Some heads up, the current state on the big reformat can be reviewed here > > https://github.com/apache/hbase/pull/4312 > > Shout if you have any questions about the formatter, we could try to tweak > the eclipse formatter to see if it could work as expected. > > Thanks. > > Andrew Purtell 于2022年4月3日周日 02:34写道： > >> I think we have consensus to move forward with application of the PRs, so >> let's fine tune the formatting configuration, and then regenerate and >> apply >> them. >> >> >> On Thu, Mar 31, 2022 at 11:03 PM 张铎(Duo Zhang) >> wrote: >> >> > FWIW, you could do a 'git reset --hard' to the commit before the big >> > reformat and do a 'git blame' again on command line. >> > >> > Nick Dimiduk 于2022年4月1日周五 13:58写道： >> > >> > > I noticed that GitHub’s blame UI has a “show before this commit” >> feature, >> > > which allowed me to look at the blame info before the reformat was >> > applied. >> > > I assume the same is possible on the command line. >> > > >> > > On Fri, Apr 1, 2022 at 04:06 张铎(Duo Zhang) >> > wrote: >> > > >> > > > +1 >> > > > >> > > > Andrew Purtell 于2022年4月1日周五 06:18写道： >> > > > >> > > > > Now that I understand what 'ratchetFrom' in the plugin >> configuration >> > > was >> > > > > doing, I have removed it, and resubmitted the PRs. They are all >> > > > ridiculous >> > > > > and expected. Just about every file in the source is touched. On >> > master >> > > > > branch 4679 files are modified out of 5507 (excluding .git/). >> There >> > are >> > > > > similar results for other branches. >> > > > > >> > > > > I think we should first spot check the PRs to determine if >> spotless >> > > > > configuration should be fine tuned. Then once it is acceptable the >> > PRs >> > > > can >> > > > > be updated with a re-application. Merging them applies a one shot >> > > > > reformatting to all live branches. This is desirable so that going >> > > > forward >> > > > > it will be easier for reviewers and committers to manage PRs and >> > > commits >> > > > to >> > > > > multiple branches. Put another way, if we don't do it, merge >> > conflicts >> > > > are >> > > > > more likely. >> > > > > >> > > > > By adopting spotless and a particular configuration as our coding >> > > > standard, >> > > > > and by opting in to automatic application of that policy as part >> of >> > our >> > > > > patch submission process, we also agree that a discontinuity in >> > history >> > > > > (i.e. 'git blame' will be less useful prior to the application of >> the >> > > > > reformatting than afterward) is an acceptable trade off. If this >> is >> > > true >> > > > we >> > > > > can move forward. If not it needs more discussion. >> > > > > >> > > > > >> > > > > On Mon, Mar 28, 2022 at 7:08 PM Andrew Purtell < >> apurt...@apache.org> >> > > > > wrote: >> > > > > >> > > > > > Yes, I figure we should run spotless on all live branch-2x >> branches >> > > to >> > > > > get >> > > > > > a baseline for future contributions and backports. >> > > > > > >> > > > > > On Mon, Mar 28, 2022 at 6:50 PM 张铎(Duo Zhang) < >> > palomino...@gmail.com >> > > > >> > > > > > wrote: >> > > > > > >> > > > > >> I’m natural on this. We could remove the ratchetFrom config and >> > do a >> > > > > full >> > > > > >> reformat on all branches. The problem is git blame will be >> > useless… >> > > > > >> >> > > > > >> But anyway, if the file has been touched later, git blame will >> be >> > > > broken >> > > > > >> too. >> > > > > >> >> > > > > >> I saw Andrew has already opened a PR. Let’s get it done. >> > > > > >> >> > > > > >> Thanks. >> > > > > >> >> > > > > >> Bryan Beaudreault > .invalid>于2022年3月29日 >> > > > > >> 周二00:55写道： >> > > > > >> >> > > > > >> > Thanks for your work here Duo! >> > > > > >> > >> > > > > >> > What should be our convention on committing unrelated >> formatting >> > > > > changes >> > > > > >> > due to spotless? For example, I have a PR >> > > > > >> > https://github.com/apache/hbase/pull/4180 open. I rebased >> it on >> > > > > latest >> > > > > >> > master to pull in spotless and ran `mvn spotless:apply` as >> > > > suggested. >> > > > > As >> > > > > >> > you said in the jira, it properly only applied to the files I >> > > > touched. >> > > > > >> But >> > > > > >> > some of those files I touched had lots of formatting changes >> > > > unrelated >> > > > > >> to >> > > > > >> > my changes. I imagine this will make it harder to review. >> > > > > >> > >> > > > > >> > I wonder if we should do a
[jira] [Resolved] (HBASE-26971) SnapshotInfo --snapshot param is marked as required even when trying to list all snapshots
[ https://issues.apache.org/jira/browse/HBASE-26971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wellington Chevreuil resolved HBASE-26971. -- Resolution: Fixed Merged to master, branch-2, branch-2.5 and branch-2.4. Thanks for reviewing, [~elserj] ! > SnapshotInfo --snapshot param is marked as required even when trying to list > all snapshots > -- > > Key: HBASE-26971 > URL: https://issues.apache.org/jira/browse/HBASE-26971 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.5.0, 3.0.0-alpha-2, 2.4.11 >Reporter: Wellington Chevreuil >Assignee: Wellington Chevreuil >Priority: Minor > Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3, 2.4.12 > > > SnapshotInfo –-list-snapshots lists all existing snapshots and doesn't need > any filter, however, --snapshot param is marked as required, causing list to > fail if this param is not defined. > Also, the help description is a bit confusing about which options should be > used together. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26978) Update inmemory_compaction.adoc
Xuesen Liang created HBASE-26978: Summary: Update inmemory_compaction.adoc Key: HBASE-26978 URL: https://issues.apache.org/jira/browse/HBASE-26978 Project: HBase Issue Type: Bug Components: documentation Reporter: Xuesen Liang Assignee: Xuesen Liang The default value of _hbase.hregion.compacting.memstore.type_ was changed from _BASIC_ to _DEFAULT_ by [HBASE-20539|https://issues.apache.org/jira/browse/HBASE-20539]. We should update its doc _inmemory_compaction.adoc_ accordingly. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-26977) HMaster's ShutdownHook does not take effect, if tablesOnMaster is false
LiangJun He created HBASE-26977: --- Summary: HMaster's ShutdownHook does not take effect, if tablesOnMaster is false Key: HBASE-26977 URL: https://issues.apache.org/jira/browse/HBASE-26977 Project: HBase Issue Type: Bug Components: master Reporter: LiangJun He Assignee: LiangJun He -- This message was sent by Atlassian Jira (v8.20.7#820007)
