[jira] [Created] (HBASE-28581) Remove deprecated methods in TableDescriptor
Duo Zhang created HBASE-28581: - Summary: Remove deprecated methods in TableDescriptor Key: HBASE-28581 URL: https://issues.apache.org/jira/browse/HBASE-28581 Project: HBase Issue Type: Sub-task Components: API, Client Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28580) Remove deprecated methods in WALObserver
Duo Zhang created HBASE-28580: - Summary: Remove deprecated methods in WALObserver Key: HBASE-28580 URL: https://issues.apache.org/jira/browse/HBASE-28580 Project: HBase Issue Type: Sub-task Components: Coprocessors, wal Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28579) Hide HFileScanner related methods in StoreFileReader
Duo Zhang created HBASE-28579: - Summary: Hide HFileScanner related methods in StoreFileReader Key: HBASE-28579 URL: https://issues.apache.org/jira/browse/HBASE-28579 Project: HBase Issue Type: Sub-task Components: HFile, Scanners Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28578) Remove deprecated methods in HFileScanner
Duo Zhang created HBASE-28578: - Summary: Remove deprecated methods in HFileScanner Key: HBASE-28578 URL: https://issues.apache.org/jira/browse/HBASE-28578 Project: HBase Issue Type: Sub-task Components: HFile, Scanners Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28577) Remove deprecated methods in KeyValue
Duo Zhang created HBASE-28577: - Summary: Remove deprecated methods in KeyValue Key: HBASE-28577 URL: https://issues.apache.org/jira/browse/HBASE-28577 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28576) Remove FirstKeyValueMatchingQualifiersFilter
Duo Zhang created HBASE-28576: - Summary: Remove FirstKeyValueMatchingQualifiersFilter Key: HBASE-28576 URL: https://issues.apache.org/jira/browse/HBASE-28576 Project: HBase Issue Type: Sub-task Components: Filters Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Dropping Java 8 support in HBase 3
In my experience, there are a few notable areas where core refactoring is happening. Most contributions don’t happen in those areas, and as a result could be cleanly backported if not for gotchas like HBaseTestingUtil rename. Anyway I agree that just adding a compile check is easier. That said, I would still advocate for not diverging the jdk version from branch-2. In my opinion almost all commits should be backported to branch-2. The only exceptions are for specific incompatibile/unsafe 3.x features. The reason for that is we don’t do major releases nearly often enough, so backporting to branch-2 is the only way to get changes into users hands. So if this change is going to make that much more difficult then personally I’d prefer a more aggressive approach of bumping jdk for branch-2, or a more conservative approach of not allowing new language features in branch-3. Overall I think more frequent smaller major releases would help us be more agile, and aligns more with other modern projects I’ve seen. On Tue, May 7, 2024 at 10:00 AM Istvan Toth wrote: > I'd expect the automated backporting process to only work for fairly > trivial patches which do not use protobuf, etc. > More involved patches would need manual work anyway. > > If we want to make sure that everything compiles with JDK8, it's easier to > just compile the master branch with JDK8 (along with 11/17), > and fail the CI check if it doesn't. > > We need to find a balance between using the new Java features and keeping > the workload manageable. > We could keep compiling master with JDK8 for a year or two, and when > activity on the 2.x branches tapers off, we could remove that restriction. > > > On Tue, May 7, 2024 at 3:56 PM Andrew Purtell > wrote: > > > I also like the suggestion to have CI help us here too. > > > > > On May 7, 2024, at 9:42 AM, Bryan Beaudreault > > > wrote: > > > > > > I'm nervous about creating more big long-term divergences between the > > > branches. Already I sometimes get caught up on HBaseTestingUtil vs > > > HBaseTestingUtility. And we all know the burden of maintaining the old > > > HTable impl. > > > > > > I'm not sure if this is a useful suggestion since it would require > > someone > > > to do a good deal of work, but I wonder if we could automate backport > > > testing a bit. Our yetus checks already check the patch, maybe it could > > > apply the patch to branch-2. This would increase the cost of master > > branch > > > PRs but maybe speed us up overall. > > > > > >> On Tue, May 7, 2024 at 9:21 AM 张铎(Duo Zhang) > > wrote: > > >> > > >> The problem is that, if we only compile and run tests on JDK11+, the > > >> contributors may implicitly use some JDK11+ only features and > > >> introduce difference when backporting to branch-2.x. > > >> > > >> Maybe a possible policy is that, once a patch should go into > > >> branch-2.x too, before mering the master PR, we should make sure the > > >> contributor open a PR for branch-2.x too, so we can catch the > > >> differences between the 2 PRs, and whether to align them. > > >> > > >> WDYT? > > >> > > >> Thanks. > > >> > > >> Andrew Purtell 于2024年5月7日周二 20:20写道： > > >>> > > >>> I don’t expect 2.x to wind down for up to several more years. We will > > be > > >>> still using it in production at my employer for a long time and I > would > > >>> continue my role as RM for 2.x as needed. HBase 3 is great but not GA > > yet > > >>> and then some users will want to wait one to a couple years before > > >> adopting > > >>> the new major version, especially if migration is not seamless. (We > > even > > >>> faced breaking changes in a minor upgrade from 2.4 to 2.5 that > brought > > >> down > > >>> a cluster during a rolling upgrade, so there should be no expectation > > of > > >> a > > >>> seamless upgrade.) My plan is to continue releasing 2.x until, like > > with > > >>> 1.x, the commits to branch-2 essentially stop, or until the PMC stops > > >>> allowing release of the candidates. > > >>> > > >>> Perhaps we do not need to do a total ban on use of 11 features. We > > should > > >>> allow a case by case discussion. We can minimize their scope and even > > >>> potentially offer multiversion support like we do with Unsafe access > > >>> utility classes in hbase-thirdparty. There are no planned uses of new > > 11+ > > >>> APIs and features now anyhow. > > >>> > > >>> > > >>> On Tue, May 7, 2024 at 7:40 AM 张铎(Duo Zhang) > > >> wrote: > > >>> > > For me I think Istvan's plan is also acceptable. > > > > So in conclusion, we should > > > > 1. Jump to JDK11/JDK17(we could start a new thread to discuss this, > > maybe also on the user mailing list) > > 2. Claim and also make sure 3.x does not work with JDK8 > > 3. Introduce a policy to only allow JDK8 features on master and > > branch-3.x for a while(maybe still keep the release version as 8?) > > > > Any other suggestions? > > > > Thanks. > > > > Istvan
[jira] [Resolved] (HBASE-28563) Closing ZooKeeper in ZKMainServer
[ https://issues.apache.org/jira/browse/HBASE-28563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28563. --- Fix Version/s: 2.4.18 2.7.0 3.0.0-beta-2 2.6.1 2.5.9 Hadoop Flags: Reviewed Resolution: Fixed Pushed to all active branches. Thanks [~minwoo.kang] for contributing and [~andor] for reviewing! > Closing ZooKeeper in ZKMainServer > - > > Key: HBASE-28563 > URL: https://issues.apache.org/jira/browse/HBASE-28563 > Project: HBase > Issue Type: Improvement > Components: Zookeeper >Reporter: Minwoo Kang >Assignee: Minwoo Kang >Priority: Minor > Labels: pull-request-available > Fix For: 2.4.18, 2.7.0, 3.0.0-beta-2, 2.6.1, 2.5.9 > > > Users can switch the Zookeeper client/server communication framework to Netty. > ZKMainServer process fails to terminate due to when users utilize Netty for > ZooKeeper connections. > Netty threads identified as non-Daemon threads. > Enforce the calling of close() on ZooKeeper before ZKMainServer termination. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28575) Always printing error log when snapshot table
[ https://issues.apache.org/jira/browse/HBASE-28575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28575. --- Fix Version/s: 2.4.18 2.7.0 3.0.0-beta-2 2.6.1 2.5.9 Hadoop Flags: Reviewed Resolution: Fixed Pushed to all active branches. Thanks [~guluo] for contributing! > Always printing error log when snapshot table > -- > > Key: HBASE-28575 > URL: https://issues.apache.org/jira/browse/HBASE-28575 > Project: HBase > Issue Type: Bug > Components: snapshots >Affects Versions: 2.4.13 > Environment: hbase2.4.13 > Centos7 >Reporter: guluo >Assignee: guluo >Priority: Minor > Labels: pull-request-available > Fix For: 2.4.18, 2.7.0, 3.0.0-beta-2, 2.6.1, 2.5.9 > > > Reproduction. > 1. > Disable snapshot procedure if your hbase support snapshot procedure feature > Set hbase.snapshot.procedure.enabled to false to disable snapshot procedure. > 2. > Executing snapshot against a table, this step is no problem > snapshot 't01', 'sn0001' > 3. > HBase outputs error logs, as follow. > 2024-05-07T23:16:37,175 ERROR > [MASTER_SNAPSHOT_OPERATIONS-master/archlinux:16000-0] > snapshot.TakeSnapshotHandler: Couldn't delete snapshot working > directory:file:/opt/hbase/hbase-4.0.0-alpha-1-SNAPSHOT/tmp/hbase/.hbase-snapshot/.tmp/sn001 > > The Reason. > HBase would clean tmp of the snapshot after snapshot. > The tmp would be empty if snapshot was executed successfully > We would get false when calling `Filesystem.delete()` to delete the tmp which > does not exist, so hbase outputs error logs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28570) Remove deprecated fields in HBTU
[ https://issues.apache.org/jira/browse/HBASE-28570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28570. --- Fix Version/s: 3.0.0-beta-2 Hadoop Flags: Reviewed Release Note: Remove TEST_DIRECTORY_KEY field in HBTU. It is private so should not cause any compilation error. Resolution: Fixed > Remove deprecated fields in HBTU > > > Key: HBASE-28570 > URL: https://issues.apache.org/jira/browse/HBASE-28570 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Labels: pull-request-available > Fix For: 3.0.0-beta-2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
