Re: [VOTE] Merge feature branch HBASE-27109 back to master

[Yu Li]

+1

Thanks all for the efforts!

Best Regards,
Yu


On Fri, 12 May 2023 at 10:17, tianhang tang  wrote:

> +1
>
> 张铎(Duo Zhang)  于2023年5月10日周三 21:20写道：
> >
> > Oh, it seems finally the 3 VOTE emails are all sent...
> >
> > Sorry for the spam...
> >
> > Liangjun He <2005hit...@163.com> 于2023年5月10日周三 19:36写道：
> >
> > > +1
> > >
> > >
> > > At 2023-05-10 01:13:12, "张铎(Duo Zhang)"  wrote:
> > > >The issue is about moving replication queue storage from zookeeper to
> a
> > > >hbase table. This is the last piece of persistent data on zookeeper.
> So
> > > >after this feature merged, we are finally fine to say that all data on
> > > >zookeeper can be removed while restarting a cluster.
> > > >
> > > >Let me paste the release note here
> > > >
> > > >We introduced a table based replication queue storage in this issue.
> The
> > > >> queue data will be stored in hbase:replication table. This is the
> last
> > > >> piece of persistent data on zookeeper. So after this change, we are
> OK
> > > to
> > > >> clean up all the data on zookeeper, as now they are all transient, a
> > > >> cluster restarting can fix everything.
> > > >>
> > > >> The data structure has been changed a bit as now we only support an
> > > offset
> > > >> for a WAL group instead of storing all the WAL files for a WAL
> group.
> > > >> Please see the replication internals section in our ref guide for
> more
> > > >> details.
> > > >>
> > > >> To break the cyclic dependency issue, i.e, creating a new WAL writer
> > > >> requires writing to replication queue storage first but with table
> based
> > > >> replication queue storage, you first need a WAL writer when you
> want to
> > > >> update to table, now we will not record a queue when creating a new
> WAL
> > > >> writer instance. The downside for this change is that, the logic for
> > > >> claiming queue and WAL cleaner are much more complicated. See
> > > >> AssignReplicationQueuesProcedure and ReplicationLogCleaner for more
> > > details
> > > >> if you have interest.
> > > >>
> > > >> Notice that, we will use a separate WAL provider for
> hbase:replication
> > > >> table, so you will see a new WAL file for the region server which
> holds
> > > the
> > > >> hbase:replication table. If we do not do this, the update to
> > > >> hbase:replication table will also generate some WAL edits in the WAL
> > > file
> > > >> we need to track in replication, and then lead to more updates to
> > > >> hbase:replication table since we have advanced the replication
> offset.
> > > In
> > > >> this way we will generate a lot of garbage in our WAL file, even if
> we
> > > >> write nothing to the cluster. So a separated WAL provider which is
> not
> > > >> tracked by replication is necessary here.
> > > >>
> > > >> The data migration will be done automatically during rolling
> upgrading,
> > > of
> > > >> course the migration via a full cluster restart is also supported,
> but
> > > >> please make sure you restart master with new code first. The
> replication
> > > >> peers will be disabled during the migration and no claiming queue
> will
> > > be
> > > >> scheduled at the same time. So you may see a lot of unfinished SCPs
> > > during
> > > >> the migration but do not worry, it will not block the normal
> failover,
> > > all
> > > >> regions will be assigned. The replication peers will be enabled
> again
> > > after
> > > >> the migration is done, no manual operations needed.
> > > >>
> > > >> The ReplicationSyncUp tool is also affected. The goal of this tool
> is to
> > > >> replicate data to peer cluster while the source cluster is down.
> But if
> > > we
> > > >> store the replication queue data in a hbase table, it is impossible
> for
> > > us
> > > >> to get the newest data if the source cluster is down. So here we
> choose
> > > to
> > > >> read from the region directory directly to load all the replication
> > > queue
> > > >> data in memory, and do the sync up work. We may lose the newest
> data so
> > > in
> > > >> this way we need to replicate more data but it will not affect
> > > >> correctness.
> > > >>
> > > >
> > > > The nightly job is here
> > > >
> > > >
> > >
> https://ci-hbase.apache.org/job/HBase%20Nightly/job/HBASE-27109%252Ftable_based_rqs/
> > > >
> > > >Mostly fine, the failed UTs are not related and are flaky, for
> example,
> > > >build #73, the failed UT is TestAdmin1.testCompactionTimestamps,
> which is
> > > >not related to replication and it only failed in jdk11 build but
> passed in
> > > >jdk8 build.
> > > >
> > > >This is the PR against the master branch.
> > > >
> > > >https://github.com/apache/hbase/pull/5202
> > > >
> > > >The PR is big as we have 16 commits on the feature branch.
> > > >
> > > >The VOTE will be open for at least 72 hours.
> > > >
> > > >[+1] Agree
> > > >[+0] Neutral
> > > >[-1] Disagree (please include actionable feedback)
> > > >
> > > >Thanks.
> > >
>

Re: [ANNOUNCE] Please welcome Tak Lon (Stephen) Wu to the HBase PMC

[Yu Li]

Congrats and welcome, Stephen!

Best Regards,
Yu


On Wed, 1 Feb 2023 at 01:37, Zach York  wrote:

> Congratulations and welcome Stephen! Well deserved!
>
> On Tue, Jan 31, 2023 at 8:52 AM Rushabh Shah
>  wrote:
>
> > Congratulations Stephen !
> >
> >
> > On Mon, Jan 30, 2023 at 10:54 PM Tak Lon (Stephen) Wu  >
> > wrote:
> >
> > > Thank you everyone ! So happy to be here and will continue to interact
> > > with you guys.
> > >
> > > -Stephen
> > >
> > > On Mon, Jan 30, 2023 at 9:06 PM rajeshb...@apache.org
> > >  wrote:
> > > >
> > > > Congratulations Stephen.
> > > >
> > > >
> > > > Thanks,
> > > > Rajeshbabu.
> > > >
> > > > On Mon, Jan 30, 2023, 7:33 PM Bryan Beaudreault <
> > bbeaudrea...@gmail.com>
> > > > wrote:
> > > >
> > > > > Congrats!
> > > > >
> > > > > On Mon, Jan 30, 2023 at 4:10 AM Balazs Meszaros <
> > meszib...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Congratulations!
> > > > > >
> > > > > > On Mon, Jan 30, 2023 at 9:19 AM Jan Hentschel
> > > > > >  wrote:
> > > > > >
> > > > > > > Congratulations and welcome!
> > > > > > >
> > > > > > > From: Duo Zhang 
> > > > > > > Date: Monday, January 30, 2023 at 3:50 AM
> > > > > > > To: HBase Dev List , hbase-user <
> > > > > > > u...@hbase.apache.org>, user-zh 
> > > > > > > Subject: [ANNOUNCE] Please welcome Tak Lon (Stephen) Wu to the
> > > HBase
> > > > > PMC
> > > > > > > On behalf of the Apache HBase PMC I am pleased to announce that
> > > > > > > Tak Lon (Stephen) Wu has accepted our invitation to become a
> PMC
> > > member
> > > > > > > on the Apache HBase project. We appreciate Tak Lon (Stephen) Wu
> > > > > stepping
> > > > > > > up to take more responsibility in the HBase project.
> > > > > > >
> > > > > > > Please join me in welcoming Tak Lon (Stephen) Wu to the HBase
> > PMC!
> > > > > > >
> > > > > > > 我很高兴代表 Apache HBase PMC 宣布 Tak Lon (Stephen) Wu 已接受我们的邀请，
> > > > > > > 成为 Apache HBase 项目的 PMC 成员。感谢 Tak Lon (Stephen) Wu 愿意在 HBase
> > > > > > > 项目中承担更大的责任。
> > > > > > >
> > > > > > > 欢迎 Tak Lon (Stephen) Wu！
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>

[ANNOUNCE] New HBase Committer Liangjun He

[Yu Li]

Hi All,

On behalf of the Apache HBase PMC, I am pleased to announce that Liangjun
He (heliangjun) has accepted the PMC's invitation to become a committer on
the project. We appreciate all of Liangjun's generous contributions thus
far and look forward to his continued involvement.

Congratulations and welcome, Liangjun!

我很高兴代表 Apache HBase PMC 宣布 Liangjun He (何良均) 已接受我们的邀请，成为 Apache HBase 项目的
Committer。感谢何良均一直以来为 HBase 项目做出的贡献，并期待他在未来继续承担更多的责任。

欢迎良均！

Best Regards,
Yu
-- 
Best Regards,
Yu

Re: [VOTE] The first release candidate for HBase 2.5.2 is available

[Yu Li]

+1 (binding)

* Checked sums and signatures: OK
* Built from source: OK (8u121)
* RAT check: OK (8u121)
* Basic functions (8u121): OK
   - Local cluster start and stop: OK
   - Master and RegionServer UI: OK
   - Basic DML operations (put/delete/get/scan) and result correctness: OK
   - Basic admin operations (snapshot/compact/major_compact): OK
* Unit test pass (8u121): OK

Best Regards,
Yu

On Thu, Dec 1, 2022 at 4:25 PM Guanghao Zhang  wrote:

> +1 (binding)
>
> * Checksum : ok
> * Rat check (1.8.0_301): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_301): ok
>  - mvn clean install -DskipTests
> * Unit tests pass (1.8.0_301): ok
>  - mvn package -P runSmallTests
>
> Duo Zhang  于2022年11月30日周三 23:37写道：
>
> > Bump.
> >
> > The phoenix community has tested the hadoop3 artifacts and it works well.
> >
> > Let's get this release done~
> >
> > Thanks.
> >
> > Duo Zhang  于2022年11月24日周四 12:32写道：
> > >
> > > Please vote on this Apache hbase release candidate,
> > > hbase-2.5.2RC0
> > >
> > > The VOTE will remain open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache hbase 2.5.2
> > > [ ] -1 Do not release this package because ...
> > >
> > > The tag to be voted on is 2.5.2RC0:
> > >
> > >   https://github.com/apache/hbase/tree/2.5.2RC0
> > >
> > > This tag currently points to git reference
> > >
> > >   3e28acf0b819f4b4a1ada2b98d59e05b0ef94f96
> > >
> > > 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.5.2RC0/
> > >
> > > Maven artifacts are available in a staging repository at:
> > >
> > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1503/
> > >
> > > Maven artifacts for hadoop3 are available in a staging repository at:
> > >
> > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1504/
> > >
> > > Artifacts were signed with the 0x9AD2AE49 key which can be found in:
> > >
> > >   https://downloads.apache.org/hbase/KEYS
> > >
> > > 2.5.2 includes 28 bug and improvement fixes done since 2.5.1. And
> > > starting from 2.5.2, we will publish dist and maven artifacts for both
> > > hadoop2 and hadoop3. Feel free to report any issues for the newly
> > > published hadoop3 dist and maven artifacts.
> > >
> > > To learn more about Apache hbase, please see
> > >
> > >   http://hbase.apache.org/
> > >
> > > Thanks,
> > > Your HBase Release Manager
> >
>
-- 
Best Regards,
Yu

Re: [VOTE] First release candidate for hbase-thirdparty 4.1.2 is available for download

[Yu Li]

+1 (binding)

Checked the diff between 4.1.1 and 4.1.2-rc0: *OK* (
https://github.com/apache/hbase-thirdparty/compare/rel/4.1.1...4.1.2RC0)
Checked release note and changes: *OK*
Checked sums and signatures: *OK*
Checked the jars in the staging repo: *OK*
Checked rat, UT, and building from source (8u101): *OK*

Best Regards,
Yu


On Sat, 8 Oct 2022 at 02:30, Andrew Purtell  wrote:

> +1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_332): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_332): ok
>  - mvn clean install  -DskipTests
> * Unit tests pass (1.8.0_332): ok
>  - mvn clean package  -Dsurefire.rerunFailingTestsCount=3
> [
>
> On Fri, Oct 7, 2022 at 5:45 AM 张铎(Duo Zhang) 
> wrote:
>
> > Please vote on this Apache hbase thirdparty release candidate,
> > hbase-thirdparty-4.1.2RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase thirdparty 4.1.2
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 4.1.2RC0:
> >
> >   https://github.com/apache/hbase-thirdparty/tree/4.1.2RC0
> >
> > This tag currently points to git reference
> >
> >   c77602901d8fba57957fa4b647b0578cae687f1a
> >
> > 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/hbase-thirdparty-4.1.2RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1496/
> >
> > Artifacts were signed with the 9AD2AE49 key which can be found in:
> >
> >   https://downloads.apache.org/hbase/KEYS
> >
> > To learn more about Apache hbase thirdparty, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manage
> >
>
>
> --
> Best regards,
> Andrew
>
> Unrest, ignorance distilled, nihilistic imbeciles -
> It's what we’ve earned
> Welcome, apocalypse, what’s taken you so long?
> Bring us the fitting end that we’ve been counting on
>- A23, Welcome, Apocalypse
>

Re: [VOTE] First release candidate for hbase 3.0.0-alpha-3 is available for download

[Yu Li]

+1 (binding)

* Checked sums and signatures: *OK*
* Built from source: *OK* (8u121)
* RAT check: *OK* (8u121)
* Basic functions (8u121): *OK*
   - Local cluster start and stop: OK
   - Master and RegionServer UI: OK
   - Basic DML operations (put/delete/get/scan) and result correctness: OK
   - Basic admin operations (snapshot/compact/major_compact): OK
* Unit test pass (8u121): *FAILED (non-blocker for alpha RC)*
   - TestClusterScopeQuotaThrottle also failed in my local environment
   - The whole set didn't complete due to low local disk space

Best Regards,
Yu


On Fri, 24 Jun 2022 at 08:18, Andrew Purtell  wrote:

> +1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_332): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_332): ok
>  - mvn clean install  -DskipTests
> * Unit tests pass (1.8.0_332): failed
>  - mvn package -P runAllTests  -Dsurefire.rerunFailingTestsCount=3
>
> Unit tests for me got hung up on TestClusterScopeQuotaThrottle, but passing
> unit tests are not required for an -alpha RC.
>
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 1, Time elapsed:
> 770.16 s <<< FAILURE! - in
> org.apache.hadoop.hbase.quotas.TestClusterScopeQuotaThrottle
> [ERROR] org.apache.hadoop.hbase.quotas.TestClusterScopeQuotaThrottle  Time
> elapsed: 748.337 s  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 780
> seconds
> at java.security.AccessController.getStackAccessControlContext(Native
> Method)
> at java.security.AccessController.getContext(AccessController.java:822)
> at
>
> org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:567)
> at
>
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.(User.java:281)
> at org.apache.hadoop.hbase.security.User.getCurrent(User.java:164)
> at
>
> org.apache.hadoop.hbase.quotas.ThrottleQuotaTestUtil.triggerCacheRefresh(ThrottleQuotaTestUtil.java:154)
> at
>
> org.apache.hadoop.hbase.quotas.ThrottleQuotaTestUtil.triggerUserCacheRefresh(ThrottleQuotaTestUtil.java:107)
> at
>
> org.apache.hadoop.hbase.quotas.TestClusterScopeQuotaThrottle.testUserClusterScopeQuota(TestClusterScopeQuotaThrottle.java:174)
>
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 1.8.0_332, vendor: Azul Systems, Inc., runtime:
> /opt/java-zulu-8/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.10.0-14-arm64", arch: "aarch64", family:
> "unix"
>
> On Wed, Jun 15, 2022 at 9:05 AM 张铎(Duo Zhang) 
> wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-3.0.0-alpha-3RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 3.0.0-alpha-3
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 3.0.0-alpha-3RC0:
> >
> >   https://github.com/apache/hbase/tree/3.0.0-alpha-3RC0
> >
> > This tag currently points to git reference
> >
> >   b3657484850f9fa9679f2186bf53e7df768f21c7
> >
> > 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/3.0.0-alpha-3RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1487/
> >
> > Artifacts were signed with the 9AD2AE49 key which can be found in:
> >
> >   https://downloads.apache.org/hbase/KEYS
> >
> > 3.0.0-alpha-3 is the second alpha release for our 3.0.0 major release
> line.
> > HBase 3.0.0 includes the following big feature/changes:
> >   Synchronous Replication
> >   OpenTelemetry Tracing
> >   Distributed MOB Compaction
> >   Backup and Restore
> >   Move RSGroup balancer to core
> >   Reimplement sync client on async client
> >   CPEPs on shaded proto
> >   Move the logging framework from log4j to log4j2
> >   Decouple region replication and general replication framework, and
> >   also make region replication can work when SKIP_WAL is used
> >
> > Notice that this is not a production ready release. It is used to let our
> > users try and test the new major release, to get feedback before the
> final
> > GA release is out.
> > So please do NOT use it in production. Just try it and report back
> > everything you find unusual.
> >
> > And this time we will not include CHANGES.md and RELEASENOTE.md
> > in our source code, you can find it on the download site. For getting
> these
> > two files for old releases, please go to
> >
> >   https://archive.apache.org/dist/hbase/
> >
> > To learn more about Apache hbase, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>

Re: [VOTE] First release candidate for hbase-thirdparty 4.1.1 is available for download

[Yu Li]

Thanks for the quick reply Duo, makes sense to me.

And thanks for driving this release.

Best Regards,
Yu


On Tue, 21 Jun 2022 at 23:17, 张铎(Duo Zhang)  wrote:

> Thanks Yu.
>
> We do not write release note for HBASE-26893(my fault) so the generate
> RELEASENOTES.md does not have the release note for this change.
>
> I thought the title just tells everything so I did not add a release note
> for it...
>
> Anyway, not a blocker this time. In the future will rememer to always add a
> release note for an issue when we bump a dependency.
>
> Thanks.
>
> Yu Li  于2022年6月21日周二 23:02写道：
>
> > +1 (binding)
> >
> > Checked the diff between 4.1.0 and 4.1.1-rc0: *OK* (
> > https://github.com/apache/hbase-thirdparty/compare/rel/4.1.0...4.1.1RC0)
> > Checked release note and changes: *Minor Update Required*
> > - It seems we should also include HBASE-26893 (jackson updated to 2.13.3)
> > into release note (RELEASENOTES.md)
> > Checked sums and signatures: *OK*
> > Maven clean install from source (8u121): *OK*
> > Checked the jars in the staging repo: *OK*
> >
> > Best Regards,
> > Yu
> >
> >
> > On Tue, 21 Jun 2022 at 22:55, OpenInx  wrote:
> >
> > > +1  (binding)
> > >
> > > 1. Download the source tarball, signature (.asc), and checksum
> (.sha512):
> > >  OK
> > > 2. Import gpg keys: download KEYS and run gpg --import
> > > /path/to/downloaded/KEYS :  OK
> > > 3. Verify the signature by running: gpg --verify
> > > hbase-thirdparty-4.1.1-src.tar.gz.asc :  OK
> > > 4. Verify the checksum by running: shasum -a 512
> > > hbase-thirdparty-4.1.1-src.tar.gz :  OK
> > > 5. Untar the archive and go into the source directory: tar xzvf
> > > hbase-thirdparty-4.1.1-src.tar.gz && cd hbase-thirdparty-4.1.1:  OK
> > > 6. Run RAT checks to validate license headers: mvn apache-rat:check: OK
> > > 7. Build and test the project: mvn install (use Java 8) :   OK
> > >
> > > Thanks Duo Zhang for the great release work, and thanks all for the
> > > verification!
> > >
> > > On Tue, Jun 21, 2022 at 7:00 PM Xiaolin Ha 
> > wrote:
> > >
> > > > +1 (binding)
> > > >
> > > >  * Signature: ok
> > > >  * Checksum : ok
> > > >  * Rat check (1.8.0_202): ok
> > > >   - mvn clean apache-rat:check
> > > >  * Built from source (1.8.0_202): ok
> > > >   - mvn clean install -DskipTests
> > > >
> > > > Thanks,
> > > > Xiaolin Ha
> > > >
> > > > 张铎(Duo Zhang)  于2022年6月18日周六 23:04写道：
> > > >
> > > > > Please vote on this Apache hbase thirdparty release candidate,
> > > > > hbase-thirdparty-4.1.1RC0
> > > > >
> > > > > The VOTE will remain open for at least 72 hours.
> > > > >
> > > > > [ ] +1 Release this package as Apache hbase thirdparty 4.1.1
> > > > > [ ] -1 Do not release this package because ...
> > > > >
> > > > > The tag to be voted on is 4.1.1RC0:
> > > > >
> > > > >   https://github.com/apache/hbase-thirdparty/tree/4.1.1RC0
> > > > >
> > > > > This tag currently points to git reference
> > > > >
> > > > >   d674246a75e1d7d1d4c5ee09a2567bbfa1cec022
> > > > >
> > > > > 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/hbase-thirdparty-4.1.1RC0/
> > > > >
> > > > > Maven artifacts are available in a staging repository at:
> > > > >
> > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1488/
> > > > >
> > > > > Artifacts were signed with the 9AD2AE49 key which can be found in:
> > > > >
> > > > >   https://downloads.apache.org/hbase/KEYS
> > > > >
> > > > > To learn more about Apache hbase thirdparty, please see
> > > > >
> > > > >   http://hbase.apache.org/
> > > > >
> > > > > Thanks,
> > > > > Your HBase Release Manager
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] First release candidate for hbase-thirdparty 4.1.1 is available for download

[Yu Li]

+1 (binding)

Checked the diff between 4.1.0 and 4.1.1-rc0: *OK* (
https://github.com/apache/hbase-thirdparty/compare/rel/4.1.0...4.1.1RC0)
Checked release note and changes: *Minor Update Required*
- It seems we should also include HBASE-26893 (jackson updated to 2.13.3)
into release note (RELEASENOTES.md)
Checked sums and signatures: *OK*
Maven clean install from source (8u121): *OK*
Checked the jars in the staging repo: *OK*

Best Regards,
Yu


On Tue, 21 Jun 2022 at 22:55, OpenInx  wrote:

> +1  (binding)
>
> 1. Download the source tarball, signature (.asc), and checksum (.sha512):
>  OK
> 2. Import gpg keys: download KEYS and run gpg --import
> /path/to/downloaded/KEYS :  OK
> 3. Verify the signature by running: gpg --verify
> hbase-thirdparty-4.1.1-src.tar.gz.asc :  OK
> 4. Verify the checksum by running: shasum -a 512
> hbase-thirdparty-4.1.1-src.tar.gz :  OK
> 5. Untar the archive and go into the source directory: tar xzvf
> hbase-thirdparty-4.1.1-src.tar.gz && cd hbase-thirdparty-4.1.1:  OK
> 6. Run RAT checks to validate license headers: mvn apache-rat:check: OK
> 7. Build and test the project: mvn install (use Java 8) :   OK
>
> Thanks Duo Zhang for the great release work, and thanks all for the
> verification!
>
> On Tue, Jun 21, 2022 at 7:00 PM Xiaolin Ha  wrote:
>
> > +1 (binding)
> >
> >  * Signature: ok
> >  * Checksum : ok
> >  * Rat check (1.8.0_202): ok
> >   - mvn clean apache-rat:check
> >  * Built from source (1.8.0_202): ok
> >   - mvn clean install -DskipTests
> >
> > Thanks,
> > Xiaolin Ha
> >
> > 张铎(Duo Zhang)  于2022年6月18日周六 23:04写道：
> >
> > > Please vote on this Apache hbase thirdparty release candidate,
> > > hbase-thirdparty-4.1.1RC0
> > >
> > > The VOTE will remain open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache hbase thirdparty 4.1.1
> > > [ ] -1 Do not release this package because ...
> > >
> > > The tag to be voted on is 4.1.1RC0:
> > >
> > >   https://github.com/apache/hbase-thirdparty/tree/4.1.1RC0
> > >
> > > This tag currently points to git reference
> > >
> > >   d674246a75e1d7d1d4c5ee09a2567bbfa1cec022
> > >
> > > 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/hbase-thirdparty-4.1.1RC0/
> > >
> > > Maven artifacts are available in a staging repository at:
> > >
> > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1488/
> > >
> > > Artifacts were signed with the 9AD2AE49 key which can be found in:
> > >
> > >   https://downloads.apache.org/hbase/KEYS
> > >
> > > To learn more about Apache hbase thirdparty, please see
> > >
> > >   http://hbase.apache.org/
> > >
> > > Thanks,
> > > Your HBase Release Manager
> > >
> >
>

[jira] [Resolved] (HBASE-27091) Speed up the loading of table descriptor from filesystem

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-27091.
---
Hadoop Flags: Reviewed
Release Note: Loading table descriptors with multiple threads is supported 
after HBASE-27091 (but turned off by default). The thread number could be 
configured via `hbase.tabledescriptor.parallel.load.threads`, and setting it 
back to zero will turn off the feature.
  Resolution: Implemented

Merged into master via c6298c7.

Thanks [~heliangjun] for the contribution and [~huaxiangsun] for the review.

> Speed up the loading of table descriptor from filesystem
> 
>
> Key: HBASE-27091
> URL: https://issues.apache.org/jira/browse/HBASE-27091
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 3.0.0-alpha-3
>Reporter: LiangJun He
>Assignee: LiangJun He
>Priority: Minor
> Fix For: 3.0.0-alpha-4
>
>
> If there are a large number of tables in the HBase cluster, it will take a 
> long time to fully load the table descriptor  from filesystem for the first 
> time.
> In our production cluster, there were 5 + tables. It took several minutes 
> to load the table descriptor from filesystem. This problem seriously affects 
> the performance of HMaster active/standby switchover.
> We should support concurrent loading to solve this problem.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (HBASE-27122) TestMultiRespectsLimits.testBlockMultiLimits is flaky

[Yu Li (Jira)]

Yu Li created HBASE-27122:
-

 Summary: TestMultiRespectsLimits.testBlockMultiLimits is flaky
 Key: HBASE-27122
 URL: https://issues.apache.org/jira/browse/HBASE-27122
 Project: HBase
  Issue Type: Bug
  Components: test
Reporter: Yu Li


This test case failed twice in the pre-commit 
[jdk8|https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4493/7/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt]
 and 
[jdk11|https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4493/7/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt]
 checks for PR-4493



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (HBASE-27040) Optimize the log display of the ZKProcedureUtil.java

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-27040.
---
Resolution: Fixed

Merged into master via b787648. Thanks for the contribution [~heliangjun]

> Optimize the log display of the ZKProcedureUtil.java
> 
>
> Key: HBASE-27040
> URL: https://issues.apache.org/jira/browse/HBASE-27040
> Project: HBase
>  Issue Type: Improvement
>  Components: proc-v2
>Affects Versions: 3.0.0-alpha-3
>Reporter: LiangJun He
>Assignee: LiangJun He
>Priority: Minor
> Fix For: 3.0.0-alpha-3
>
> Attachments: image-2022-05-16-11-51-14-326.png
>
>
> !image-2022-05-16-11-51-14-326.png!



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (HBASE-26998) TestRegionProcessRowsWithLocks#testProcessExceptionAndRollBack is broken in branch-1

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-26998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-26998.
---
Fix Version/s: 1.7.2
 Hadoop Flags: Reviewed
   Resolution: Fixed

> TestRegionProcessRowsWithLocks#testProcessExceptionAndRollBack is broken in 
> branch-1
> 
>
> Key: HBASE-26998
> URL: https://issues.apache.org/jira/browse/HBASE-26998
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.7.1
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Major
> Fix For: 1.7.2
>
>
> As titled, I found that 
> {{TestRegionProcessRowsWithLocks#testProcessExceptionAndRollBack}} is broken 
> while reviewing the PR for HBASE-26977 ([pre-commit test log 
> here|https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4377/7/artifact/out/patch-unit-hbase-server.txt])
>  with below exceptions:
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 10.166 s <<< FAILURE! - in 
> org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks
> [ERROR] 
> testProcessExceptionAndRollBack(org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks)
>   Time elapsed: 5.849 s  <<< ERROR!
> com.google.protobuf.ServiceException: Error calling method 
> hbase.pb.RowProcessorService.Process
>   at 
> org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:75)
>   at 
> org.apache.hadoop.hbase.protobuf.generated.RowProcessorProtos$RowProcessorService$BlockingStub.process(RowProcessorProtos.java:1631)
>   at 
> org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks.incrementCounter(TestRegionProcessRowsWithLocks.java:193)
>   at 
> org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks.testProcessExceptionAndRollBack(TestRegionProcessRowsWithLocks.java:173)
> {noformat}
> Manually test the single case in my local environment also failed. Using 
> {{git bisect}}, I found the issue was introduced by HBASE-26393 and have been 
> existing for several months (since Oct 23, 2021).
> The fix is straight forward and I will prepare a PR soon.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (HBASE-26943) HMaster page style display confusion

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-26943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-26943.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Thanks for checking [~heliangjun], and thanks [~ndimiduk] for review.

Please note that the fix is only merged into branch-2 instead of any special 
release branch such as branch-2.4, and we depend on RMs to do cherry-pick if 
decide to include this.

Closing the JIRA as fixed since all issues resolved.

> HMaster page style display confusion
> 
>
> Key: HBASE-26943
> URL: https://issues.apache.org/jira/browse/HBASE-26943
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 3.0.0-alpha-3, 2.4.12
>Reporter: LiangJun He
>Assignee: LiangJun He
>Priority: Minor
> Fix For: 2.6.0, 3.0.0-alpha-3
>
> Attachments: branch-1-hmaster.png, procedure_before.png, 
> procedure_good.png, usertable_before.png, usertable_good.png
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (HBASE-26998) TestRegionProcessRowsWithLocks#testProcessExceptionAndRollBack is broken in branch-1

[Yu Li (Jira)]

Yu Li created HBASE-26998:
-

 Summary: 
TestRegionProcessRowsWithLocks#testProcessExceptionAndRollBack is broken in 
branch-1
 Key: HBASE-26998
 URL: https://issues.apache.org/jira/browse/HBASE-26998
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 1.7.1
Reporter: Yu Li
Assignee: Yu Li


As titled, I found that 
{{TestRegionProcessRowsWithLocks#testProcessExceptionAndRollBack}} is broken 
while reviewing the PR for HBASE-26977 ([pre-commit test log 
here|https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4377/7/artifact/out/patch-unit-hbase-server.txt])
 with below exceptions:

{noformat}
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.166 
s <<< FAILURE! - in 
org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks
[ERROR] 
testProcessExceptionAndRollBack(org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks)
  Time elapsed: 5.849 s  <<< ERROR!
com.google.protobuf.ServiceException: Error calling method 
hbase.pb.RowProcessorService.Process
at 
org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:75)
at 
org.apache.hadoop.hbase.protobuf.generated.RowProcessorProtos$RowProcessorService$BlockingStub.process(RowProcessorProtos.java:1631)
at 
org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks.incrementCounter(TestRegionProcessRowsWithLocks.java:193)
at 
org.apache.hadoop.hbase.regionserver.TestRegionProcessRowsWithLocks.testProcessExceptionAndRollBack(TestRegionProcessRowsWithLocks.java:173)
{noformat}

Manually test the single case in my local environment also failed. Using {{git 
bisect}}, I found the issue was introduced by HBASE-26393 and have been 
existing for several months (since Oct 23, 2021).

The fix is straight forward and I will prepare a PR soon.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (HBASE-26976) Update related comments after HMaster can load the live RS infos from local region

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-26976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-26976.
---
Hadoop Flags: Reviewed
  Resolution: Done

Merged into master via b0c2832. Thanks [~heliangjun] for the contribution and 
[~zhangduo] for the review.

> Update related comments after HMaster can load the live RS infos from local 
> region
> --
>
> Key: HBASE-26976
> URL: https://issues.apache.org/jira/browse/HBASE-26976
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 3.0.0-alpha-3
>Reporter: LiangJun He
>Assignee: LiangJun He
>Priority: Minor
> Fix For: 3.0.0-alpha-3
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: [ANNOUNCE] New HBase committer Bryan Beaudreault

[Yu Li]

Congrats and welcome, Bryan!

Best Regards,
Yu


On Tue, 26 Apr 2022 at 22:15, Josh Elser  wrote:

> 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！
>

[jira] [Resolved] (HBASE-26951) HMaster should exit gracefully, when stopped via hbase-daemon.sh

[Yu Li (Jira)]

 [ 
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)

[jira] [Reopened] (HBASE-26943) HMaster page style display confusion

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-26943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li reopened HBASE-26943:
---

Thanks for chiming in [~ndimiduk].

The original change for this JIRA was exactly editing the css definitions 
inline in the html, it's me that asked [~heliangjun] to do the formatting. 
Sorry but I was lack of the knowledge for minimized resource, while one thing I 
cared about was whether the change is easy to track (changes in the one-liner 
way seems pretty hard to tell).

About the commit format, since the changes are separated into two commits, only 
one of them (242a194b3c) matches the summary (title) of the JIRA while the 
other (d0318732b7) doesn't. Would you mind teach me the correct way? Only one 
commit is allowed for one JIRA and the commit message must match the title of 
the JIRA? I haven't been merging commits for a while so there might be some 
rules I forgot or some new ones that I don't know, and I'd love to (re)learn 
and follow up. Thanks.

I've reopened the issue for further discussion, and will revert and re-commit 
the changes once required updates done and get [~ndimiduk]'s +1.

> HMaster page style display confusion
> 
>
> Key: HBASE-26943
> URL: https://issues.apache.org/jira/browse/HBASE-26943
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 3.0.0-alpha-3
>Reporter: LiangJun He
>Assignee: LiangJun He
>Priority: Minor
> Fix For: 3.0.0-alpha-3
>
> Attachments: procedure_before.png, procedure_good.png, 
> usertable_before.png, usertable_good.png
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (HBASE-26943) HMaster page style display confusion

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-26943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-26943.
---
Resolution: Resolved

Merged into master branch via d0318732b7 and 242a194b3c

Thanks [~heliangjun] for the contribution.

> HMaster page style display confusion
> 
>
> Key: HBASE-26943
> URL: https://issues.apache.org/jira/browse/HBASE-26943
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 3.0.0-alpha-3
>Reporter: LiangJun He
>Assignee: LiangJun He
>Priority: Minor
> Fix For: 3.0.0-alpha-3
>
> Attachments: procedure_before.png, procedure_good.png, 
> usertable_before.png, usertable_good.png
>
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (HBASE-26952) TestRaceBetweenSCPAndTRSP is flaky in master branch

[Yu Li (Jira)]

Yu Li created HBASE-26952:
-

 Summary: TestRaceBetweenSCPAndTRSP is flaky in master branch
 Key: HBASE-26952
 URL: https://issues.apache.org/jira/browse/HBASE-26952
 Project: HBase
  Issue Type: Bug
  Components: test
Reporter: Yu Li


Observed in [pre-commit 
check|https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4341/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt]
 of HBASE-26943



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [VOTE] The first release condidate for hbase-thirdparty 4.0.1 is available for download

[Yu Li]

+1 (binding)

Checked the diff between 4.0.0 and 4.0.1-rc0: OK (
https://github.com/apache/hbase-thirdparty/compare/rel/4.0.0...4.0.1RC0)
Checked release note and changes: OK
- Minor: for the CHANGES.md doc, shall we update the description of
published releases from "Unreleased" to "Released"?
Checked sums and signatures: OK
Maven clean install from source (11.0.4): OK
Checked the jars in the staging repo: OK

Best Regards,
Yu


On Sat, 25 Dec 2021 at 06:49, Andrew Purtell  wrote:

> +1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_312): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_312): ok
>  - mvn clean install  -DskipTests
>
> Built the current head of master branch with
> -Dhbase-thirdparty.version=4.0.1 and tests looked good, except the
> hbase-http module unit test expected to fail at this point.
>
>
> On Fri, Dec 17, 2021 at 7:17 AM Duo Zhang  wrote:
>
> > Please vote on this Apache hbase thirdparty release candidate,
> > hbase-thirdparty-4.0.1RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase thirdparty 4.0.1
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 4.0.1RC0:
> >
> >   https://github.com/apache/hbase-thirdparty/tree/4.0.1RC0
> >
> > This tag currently points to git reference
> >
> >   15fc52e69a8646f0a7fcaa27a2a8c4104269b125
> >
> > 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/hbase-thirdparty-4.0.1RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1475/
> >
> > Artifacts were signed with the 9AD2AE49 key which can be found in:
> >
> >   https://downloads.apache.org/hbase/KEYS
> >
> > This release is to fix the broken hbase-shaded-protobuf module. See
> > HBASE-26592 for more details.
> >
> > To learn more about Apache hbase thirdparty, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] The second release condidate for hbase-thirdparty 4.0.0 is available for download

[Yu Li]

+1

Checked the diff between 3.5.1 and 4.0.0-rc1: OK (
https://github.com/apache/hbase-thirdparty/compare/rel/3.5.1...4.0.0RC1)
Checked release note and changes: OK
Checked sums and signatures: OK
Maven clean install from source (1.8.0_121): OK
- Minor: I tried to build a tarball from source following README but failed
with "No assembly descriptors found" error
Checked the jars in the staging repo: OK

btw, I haven't followed up for a while and could anyone kindly let me know
where to find this fancy hbase-vote.sh script, so next time I could also
try it out? Thanks :-)

Best Regards,
Yu


On Fri, 10 Dec 2021 at 05:46, Nick Dimiduk  wrote:

> +1
>
> I've used the hbase-vote.sh script to evaluate this artifact and there's a
> problem in the final `run_tests` , executed after `build_from_source`.
>
> * Signature: ok
> * Checksum : ok
> * Rat check (11.0.11): ok
>  - mvn clean apache-rat:check
> * Built from source (11.0.11): ok
>  - mvn clean install  -DskipTests
> * Unit tests pass (11.0.11): failed
>  - mvn package -P runAllTests  -Dsurefire.rerunFailingTestsCount=3
>
> [WARNING] The requested profile "runAllTests" could not be activated
> because it does not exist.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.2.4:shade (default) on
> project hbase-shaded-jackson-jaxrs-json-provider: Error creating shaded
> jar: duplicate entry:
> META-INF/services/org.apache.hbase.thirdparty.javax.ws.rs
> .ext.MessageBodyWriter
>
> Manually running `mvn clean package` within the source tarball, we succeed.
>
> I have also triggered a PR build of HBASE-25864 / PR#3243 that uses this
> RC. The tests are still running.
>
> https://ci-hadoop.apache.org/blue/organizations/jenkins/HBase%2FHBase-PreCommit-GitHub-PR/detail/PR-3243/5/pipeline/
>
> On Tue, Dec 7, 2021 at 6:02 PM 张铎(Duo Zhang) 
> wrote:
>
> > Ah, Thanks Nick for explaining and thanks Andrew for testing.
> >
> > We still need one more +1 to close this vote.
> >
> > Andrew Purtell  于2021年12月7日周二 05:50写道：
> >
> > > Ok, change my vote to +1 (binding). The hbase-thirdparty build and
> > > artifacts are good.
> > >
> > > > On Dec 6, 2021, at 1:18 PM, Nick Dimiduk 
> wrote:
> > > >
> > > > On Mon, Dec 6, 2021 at 11:49 AM Andrew Purtell  >
> > > wrote:
> > > >
> > > >> -1 (binding)
> > > >>
> > > >> Checked sums and signature, ok
> > > >> RAT check passed, ok
> > > >> Built from source, ok
> > > >> Built HEAD of master (d9315fa043) with
> > -Dhbase-thirdparty.version=4.0.0,
> > > >> hbase-http module tests fail
> > > >>
> > > >
> > > > Adoption of this dependency will require changes to master. I had
> > posted
> > > > necessary changes on https://github.com/apache/hbase/pull/3243 and
> Duo
> > > did
> > > > his own on https://github.com/apache/hbase/pull/3910.
> > > >
> > > > [ERROR] Tests run: 17, Failures: 0, Errors: 1, Skipped: 2, Time
> > elapsed:
> > > >> 2.29 s <<< FAILURE! - in org.apache.hadoop.hbase.http.TestHttpServer
> > > >> [ERROR] org.apache.hadoop.hbase.http.TestHttpServer.testJersey  Time
> > > >> elapsed: 0.123 s  <<< ERROR!
> > > >> java.io.FileNotFoundException:
> > http://localhost:55106/jersey/foo?op=bar
> > > >> at
> > > >>
> > > >>
> > >
> >
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1898)
> > > >> at
> > > >>
> > > >>
> > >
> >
> sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:92)
> > > >> at
> > > >>
> > > >>
> > >
> >
> sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1492)
> > > >> at
> > > >>
> > > >>
> > >
> >
> sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1490)
> > > >> at java.security.AccessController.doPrivileged(Native Method)
> > > >> at
> > > >>
> > > >>
> > >
> >
> java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:784)
> > > >> at
> > > >>
> > > >>
> > >
> >
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1489)
> > > >> at
> > > >>
> > > >>
> > >
> >
> org.apache.hadoop.hbase.http.HttpServerFunctionalTest.readOutput(HttpServerFunctionalTest.java:248)
> > > >> at
> > > >>
> > > >>
> > >
> >
> org.apache.hadoop.hbase.http.TestHttpServer.testJersey(TestHttpServer.java:519)
> > > >>
> > > >>
> > > >>> On Fri, Dec 3, 2021 at 6:23 AM 张铎(Duo Zhang) <
> palomino...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>> Please vote on this Apache hbase thirdparty release candidate,
> > > >>> hbase-thirdparty-4.0.0RC1
> > > >>>
> > > >>> The VOTE will remain open for at least 72 hours.
> > > >>>
> > > >>> [ ] +1 Release this package as Apache hbase thirdparty 4.0.0
> > > >>> [ ] -1 Do not release this package because ...
> > > >>>
> > > >>> The tag to be voted on is 4.0.0RC1:
> > > >>>
> > > >>>  https://github.com/apache/hbase-thirdparty/tree/4.0.0RC1
> > > >>>
> > > >>> This tag currently points to git reference
> > > >>>
> > > >>>  

Re: [DISCUSS] EOL 2.3

[Yu Li]

Hi all,

Since 2.4.6 has been released on Sep. 13th and we plan to EOL 2.3.x, shall
we move the stable pointer to 2.4 (it's still on 2.3.6 for now on our
download page [1])? Or any concerns? Thanks.

Best Regards,
Yu

[1] https://hbase.apache.org/downloads.html


On Tue, 3 Aug 2021 at 06:01, Andrew Purtell 
wrote:

> I’ve been working with 2.4 for months and it is stable enough for me to +1
> moving the pointer at this time. This work includes many tests with 2.4
> using ITBLL with slowDeterministic and serverKilling policies and there has
> not been an unstable result, as defined by crashes/loss of daemons by the
> IT framework, or data issues requiring hbck.
>
> > On Aug 2, 2021, at 2:27 PM, Nick Dimiduk  wrote:
> >
> > On Mon, Aug 2, 2021 at 1:22 PM Andrew Purtell  >
> > wrote:
> >
> >> EOL of 2.3 seems premature.
> >>
> >> The stable pointer is still pointing to 2.3.
> >>
> >> Advancing the stable pointer is an obvious prerequisite. If there are
> any
> >> concerns blocking advancing the pointer to 2.4, this is where we should
> >> start the discussion.
> >>
> >
> > Point taken. I see the only conclusion of our thread [0] was to agree
> that
> > we should define "stable" criteria. I thought we'd already advanced the
> > marker.
> >
> > [0]:
> >
> https://lists.apache.org/thread.html/r1cc4528a6a35cd1b0d38398aa61ad642a368901795d6970544d0a0a9%40%3Cdev.hbase.apache.org%3E
> >
> >>> On Aug 2, 2021, at 11:23 AM, Nick Dimiduk  wrote:
> >>>
> >>> Heya,
> >>>
> >>> I'd like to start a discussion regarding the declaration of the end of
> >> life
> >>> for branch-2.3. This release line has matured nicely, but with the
> stable
> >>> pointer moving forward, and our community interest in pushing on 2.5
> and
> >>> 3.0, I think it's worth considering whether we want to continue putting
> >>> resources into this release line.
> >>>
> >>> I propose we make one final release, 2.3.7, whenever we have enough
> >> commits
> >>> to the branch, or the beginning of October, whichever comes first.
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Nick
> >>
>

Re: [ANNOUNCE] New HBase PMC Bharath Vissapragada

[Yu Li]

Congrats and welcome, Bharath!

Best Regards,
Yu


On Tue, 3 Aug 2021 at 00:27, Nick Dimiduk  wrote:

> Congratulations Bharath and thank you for all the effort you put into the
> project!
>
> On Fri, Jul 30, 2021 at 6:27 AM Viraj Jasani  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Bharath
> > Vissapragada has accepted our invitation to become a PMC member on the
> > HBase project. We appreciate Bharath stepping up to take more
> > responsibility for the project.
> >
> > Congratulations and welcome, Bharath!
> >
>

Re: Split Meta Design Reset Status

[Yu Li]

Thanks for the notes and efforts Stack, it's pretty helpful to know the
progress and latest status of the work!

Best Regards,
Yu


On Wed, 28 Jul 2021 at 12:13, Stack  wrote:

> Note, no meeting tomorrow. We'll meet next week on the 4th or 5th of
> August.
> Thanks,
> S
>
> On Thu, Jul 22, 2021 at 8:53 PM Stack  wrote:
>
> > Notes from yesterday's meeting (attendees, please amend if I misrepresent
> > or if you have anything extra to add!)
> >
> > Split Meta Design Reset Status
> >
> > Wed Jul 21 21:24:38 PDT 2021
> >
> > Attendees: Bharath, Stack, Duo, and Francis
> >
> > We went over the new updates to the Brainstorming [1] section under
> >
> > Design in the Super Split Meta Design doc [2].
> >
> > First was the new addition, 4.1.2 Extend (& Move) ConnectionRegistry;
> hide
> >
> > ROOT from Client [3]. In particular, filling out how "ROOT" might be
> >
> > implemented behind the new API in ConnectionRegistry. On option 1.,
> >
> > replicating master-local Region to RegionServers, options considered
> >
> > included
> >
> >  * Listener on master-local Region WAL to replicate.
> >
> >  * Perhaps Read-Replica but master-local is not an actual Region
> >
> >  * Needs to be incremental edits because ROOT could get too big to ship
> >
> >in a lump; need to visit how...
> >
> >  * Possibly in-memory-only Regions on RS replicated from master-local
> >
> >Region via WAL tailing <= zhang...@apache.org
> >
> >  * Which RegionServers? Those hosting ROOT replicas?
> >
> >  * How to bootstrap? Failure scenarios.
> >
> >  * This would be a new replication system alongside current; could
> >
> >evolve to replace/improve old?
> >
> > Duo offered to look into means of replicating the master-local Region
> >
> > out to RegionServers.
> >
> > Next up was discussion constrasting ROOT as a standalone table vs
> >
> > First-meta Region-as-Root (see 4.1.1 hbase:meta,,1 as ROOT [4]); i.e.
> >
> > options 2 and 3 for how we'd implement a ROOT. One item that came up
> >
> > was whether a need to specify one replica count for a ROOT table vs
> >
> > another for hbase:meta. If so, then it would be argument for ROOT as
> >
> > standalone table (Others of us argued it not a concern of consequence).
> >
> > If ROOT access is behind a new simple API in ConnectionRegistry, how
> >
> > to stop clients reading hbase:meta table if not Master or fronted by
> >
> > a ConnectionRegistry request? (Should be able to switch on client
> >
> > identity/source). One suggestion for First-meta-Region-as-ROOT was
> >
> > NOT returning the first Region to the client post-meta split when
> >
> > accessing via the simple API. Some concern this would confuse old
> >
> > Clients (Francis was going to take a look).
> >
> > Moved to discussion how we'd move ConnectionRegistry from
> >
> > hosted-by-Master to hosted-by-RegionServers. How to bootstrap such a
> >
> > system came up? Where do clients go? How do they know which
> >
> > RegionServers (special regionserver group?  Every RS fields
> >
> > ConnectionRegistry requests but only designated core serve the ROOT
> >
> > lookup APIs?). This was a TODO.
> >
> > This led naturally into 4.1.5 System RS group for client meta services
> >
> > [5], a new addition under Brainstorming. Discussion. Bharath to look
> >
> > into feedback.
> >
> > On the end of the discussion, group expressed support for adding
> >
> > simple API to the ConnectionRegistry to hide ROOT implementation
> >
> > detail from client. Support was expressed for moving ConnectionRegistry
> >
> > from Master to RegionServers. Intent is to move forward on design of
> >
> > these pieces: e.g. how client bootstraps.
> >
> > Support was expressed for getting at least the bones of a split meta
> >
> > into an hbase3 before the RCs.
> >
> > Where we'd actually store hbase:meta Region locations -- i.e. how a
> >
> > "ROOT' would be implemented -- was for our next meeting informed by
> >
> > research of the various approaches noted mostly above. It was
> >
> > also thought that the new ConnectionRegistry should not preclude
> >
> > making progress on the "ROOT" implementation.
> >
> > Will post notice of next meeting (next Weds or the one
> >
> > following).
> >
> > 1.
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.wr0fwvw06j7n
> >
> > 2.
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.9s666p6no9cq
> >
> > 3.
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.90th11txi153
> >
> > 4.
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.ikbhxlcthjle
> >
> > 5.
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.utoenf10t05b
> >
> > On Tue, Jul 20, 2021 at 11:00 AM Stack  wrote:
> >
> >> Lets meet tomorrow. Please review the design doc "Design/Brainstorming"
> >> Section 4.1 [1] before the 

Re: [ANNOUNCE] New HBase committer Baiqiang Zhao

[Yu Li]

Congrats and welcome, Baiqiang.

Best Regards,
Yu


On Mon, 12 Jul 2021 at 16:56, 哈晓琳  wrote:

> Congratulations Baiqiang!
>
> Balazs Meszaros  于2021年7月12日周一
> 下午4:35写道：
>
> > Congratulations Baiqiang!
> >
> > On Mon, Jul 12, 2021 at 9:22 AM Pankaj Kumar 
> > wrote:
> >
> > > Congratulations Baiqiang.!!
> > >
> > > Regards,
> > > Pankaj
> > >
> > > On Sun, Jul 11, 2021, 12:48 AM Nick Dimiduk 
> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > On behalf of the Apache HBase PMC I am pleased to announce that
> > Baiqiang
> > > > Zhao has accepted the PMC's invitation to become a committer on the
> > > > project!
> > > >
> > > > We appreciate all of the great contributions Baiqiang has made to
> > > > the community thus far and we look forward to his continued
> > involvement.
> > > >
> > > > Allow me to be the first to congratulate Baiqiang on his new role!
> > > >
> > > > Thanks,
> > > > Nick
> > > >
> > >
> >
>

Re: [ANNOUNCE] New HBase Committer Xiaolin Ha(哈晓琳)

[Yu Li]

Congratulations and welcome, Xiaolin Ha!

Best Regards,
Yu


On Tue, 18 May 2021 at 23:51, Ankit Singhal 
wrote:

> Congratulations Xiaolin!!
>
> On Tue, May 18, 2021 at 9:03 PM Bharath Vissapragada 
> wrote:
>
> > Congrats, Xiaolin!
> >
> > On Tue, May 18, 2021 at 1:08 AM Peter Somogyi 
> wrote:
> >
> > > Congratulations!
> > >
> > > On Mon, May 17, 2021 at 8:56 PM Wellington Chevreuil <
> > > wellington.chevre...@gmail.com> wrote:
> > >
> > > > Congratulations!
> > > >
> > > > Em seg., 17 de mai. de 2021 às 18:04, Nick Dimiduk <
> > ndimi...@apache.org>
> > > > escreveu:
> > > >
> > > > > Congratulations, Xiaolin, and thank you for all your
> contributions!!
> > > > >
> > > > > On Sat, May 15, 2021 at 7:11 AM 张铎(Duo Zhang) <
> palomino...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> > > > Xiaolin
> > > > > > Ha(sunhelly) has accepted the PMC's invitation to become a
> > committer
> > > on
> > > > > the
> > > > > > project. We appreciate all of Xiaolin's generous contributions
> thus
> > > far
> > > > > and
> > > > > > look forward to her continued involvement.
> > > > > >
> > > > > > Congratulations and welcome, Xiaolin Ha!
> > > > > >
> > > > > > 我很高兴代表Apache HBase PMC宣布哈晓琳已接受我们的邀请，成为Apache
> > > > > > HBase项目的Committer。感谢哈晓琳一直以来为HBase项目做出的贡献，并期待她在未来继续承担更多的责任。
> > > > > >
> > > > > > 欢迎哈晓琳！
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Clarifying guidance around Signed-off-by in commit messages

[Yu Li]

TL;DR: +1 for document rules / guidance of review trailers in commit
message, and +1 for continuing using the signed-off-by message for
"reviewed by" and/or "co-authored-by" semantic (committers only), adding
explicit preamble in the "Git best practice" chapter in our hbase book [1].

I did some research around signed-off-by [2] [3], reviewed-by [3] and
co-authored-by [4], and would like to share my thoughts here:

1. We have been using signed-off-by as the "reviewed by" and/or
"co-authored by" semantic for a long time, starting from the review-board
era (long before github PR).
2. I second that our usage of signed-off-by is a bit of a perversion of the
original [2], thus adding preamble as clarification is necessary.
3. Git offers a signed-off-by switch (-s/--signoff) while no reviewed-by or
co-authored-by support yet, so we need to manually type the message if
choose to use Reviewed-by or Co-authored-by trailers, which means
additional efforts.
4. Based on #3, I suggest that contributors / committers are free but not
required to add "Reviewed-by" and / or "Co-authored-by" trailers manually.
5. Regarding recognizing the review efforts of (new) non-committer
contributors, I suggest we use the Github search [5] (and the commit
efforts as well [6]).

Best Regards,
Yu

[1] http://hbase.apache.org/book.html#git.best.practices
[2]
https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for
[3] https://wiki.samba.org/index.php/CodeReview#commit_message_tags
[4]
https://docs.github.com/en/free-pro-team@latest/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors
[5] https://github.com/apache/hbase/pulls?q=is%3Apr+involves%3Acarp84
[6] https://github.com/apache/hbase/commits?author=carp84

On Mon, 23 Nov 2020 at 04:06, Sean Busbey  wrote:

> I expressly would like to see non-commiters given credit for reviews and
> have made a point of including them in prior commits for signed-off-by to
> do that.
>
> I'm fine with the idea of us using some other means to indicate this, but
> I'd like us to make sure there's not some already widely used bit of git
> metadata we could use before picking our own.
>
> It's kind of like when we moved away from amending author (I think that was
> the phrase?) To co authored by when github started pushing that as a way to
> show multiple authors on a commit.
>
> One thing to keep in mind also is that a big stumbling block to our
> consistent crediting of reviewers is a lack of tooling. Having to
> distinguish between binding and non binding reviews for putting together
> commit metadata will make that more complicated.
>
> On Fri, Nov 20, 2020, 18:15 Stack  wrote:
>
> > Thanks for taking the time to do a write up Josh.
> >
> > Looks good to me.
> >
> > When Sean started in on the 'Signed-off-by:' I didn't get it (especially
> > after reading the git definition). Sean then set me straight explaining
> our
> > use is a bit of a perversion of the original. I notice his definition is
> > not in the refguide. Suggest a sentence preamble definition of
> > 'Signed-off-by:' and that we intentionally are different from the
> > definition cited by Bharath.
> >
> > I like the Bharath idea on 'Reviewed-by' too. We can talk up
> 'Reviewed-by'
> > credits as a way to earn standing in the community, of how they are given
> > weight evaluating whether to make a candidate a committer/PMC'er or not.
> >
> > S
> >
> > On Fri, Nov 20, 2020 at 3:13 PM Josh Elser  wrote:
> >
> > > On 11/20/20 1:07 PM, Bharath Vissapragada wrote:
> > > >> * All individuals mentioned in a sign-off*must*  be capable of
> giving
> > a
> > > >> binding vote (i.e. they are an HBase committer)
> > > >>
> > > > It appears that the original intent
> > > > <
> > >
> >
> http://web.archive.org/web/20160507011446/http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
> > > >of
> > > > this sign-off feature in git mandates that the signing-off party to
> be
> > a
> > > > maintainer. So agree with you in theory. However, most times
> > > non-committers
> > > > also give great feedback and help with the code review process (code
> > > > reviews, testing, perf etc). I think acknowledging their contribution
> > in
> > > > some form would be nice and that encourages
> potential-future-committers
> > > to
> > > > actively review PRs IMO. So how about we annotate their names with
> > > > Reviewed-by tags? A related discussion
> > > > 
> > on a
> > > > different open source project has more tag definitions if we are
> > > interested
> > > > in taking that route.
> > > >
> > > > (I know you are only talking about the "signed-off by" tag but I
> > thought
> > > > this discussion would be relevant when documenting this in the dev
> > > > guidelines, hence bringing it up). What do you think?
> > >
> > > I would be happy with distinguishing Signed-off-by and Reviewed-by as a
> > > way to better track metrics on 

Re: [DISCUSS] remove "stable-1" pointer

[Yu Li]

Hi folks,

Checking our download page, it seems the stable-1 pointer is still there
[1]. Shall we take some actions as a follow-up? Thanks.

Best Regards,
Yu

[1] http://hbase.apache.org/downloads.html


On Tue, 3 Mar 2020 at 04:13, Josh Elser  wrote:

> SGTM
>
> On 3/2/20 11:53 AM, Andrew Purtell wrote:
> > The 'stable-1' pointer was a hedge at the time we decided to make the
> > 'stable' pointer point at a branch-2.x for the first time. The experience
> > has been good, so there isn't a need to hedge any longer, in my opinion.
> >
> > We should delete the stable-1 pointer.
> >
> >
> > On Mon, Mar 2, 2020 at 6:41 AM Sean Busbey  wrote:
> >
> >> I don't remember who I was chatting with, but the stable-1 pointer
> >> came up and it reminded me that I don't care for it. :)
> >>
> >> As a community we use the "stable" pointer as a way to guide
> >> downstream folks who don't want to be actively engaged in HBase
> >> internals. It's supposed to be a guidepost that says "this is our best
> >> bet on you having a low-pain experience." Right now our stance is
> >> that's a HBase 2 release.
> >>
> >> What purpose does "stable-1" serve? I previously was an advocate for
> >> it as a way to say "hey if you have to stay on HBase 1 then use this
> >> one." But as our collective effort on HBase 1 releases has waned I
> >> think the answer to that increasingly becomes "use the latest HBase 1"
> >> because we effectively can't sustain more than a single branches-1
> >> based release line.
> >>
> >> AFAIK no one is prepared to do that kind of extensive vetting of a
> >> branch-1 based release that would e.g. justify having folks stick to
> >> 1.4.z releases instead of updating to 1.6.0 when it comes out.
> >>
> >> I'm happy for various HBase 1.y lines to keep going so long as there
> >> are RMs willing to step up. I still think we should have monthly 1.4.z
> >> releases through June. But if we get into a regular cadence of
> >> releases off of branch-1 I'd rather we not provide folks with a mixed
> >> message about wether or not they'd be better of going to those newer
> >> release lines.
> >>
> >> What do folks think? Should we just delete the stable-1 pointer?
> >>
> >
> >
>

Re: [ANNOUNCE] Please welcome Lijin Bin to the HBase PMC

[Yu Li]

Congratulations and welcom, Lijin!

Best Regards,
Yu


On Wed, 27 May 2020 at 23:15, Bharath Vissapragada 
wrote:

> Congratulations, Lijin Bin.
>
> On Tue, May 26, 2020 at 9:43 PM Stack  wrote:
>
> > Hurray for Lijin Bin!
> > S
> >
> > On Mon, May 25, 2020 at 6:33 PM 宾莉金（binlijin） 
> wrote:
> >
> > > Thanks everybody. It’s an honor to join the PMC and I’ll try to do my
> > best
> > > to help the project and the community.
> > >
> > > Jan Hentschel  于2020年5月26日周二
> 上午1:37写道：
> > >
> > > > Congratulations and welcome!
> > > >
> > > > From: Guanghao Zhang 
> > > > Reply-To: "dev@hbase.apache.org" 
> > > > Date: Monday, May 25, 2020 at 4:40 PM
> > > > To: HBase Dev List , Hbase-User <
> > > > u...@hbase.apache.org>
> > > > Subject: [ANNOUNCE] Please welcome Lijin Bin to the HBase PMC
> > > >
> > > > On behalf of the Apache HBase PMC I am pleased to announce that Lijin
> > Bin
> > > > has accepted our invitation to become a PMC member on the Apache
> HBase
> > > > project. We appreciate Lijin Bin stepping up to take more
> > responsibility
> > > in
> > > > the HBase project.
> > > >
> > > > Please join me in welcoming Lijin Bin to the HBase PMC!
> > > >
> > > >
> > >
> > > --
> > > *Best Regards,*
> > >  lijin bin
> > >
> >
>

Celebrating our 10th birthday for Apache HBase

[Yu Li]

Dear HBase developers and users,
亲爱的HBase开发者和用户们，

It has been a decade since Apache HBase became an Apache top level project
[1]. Ten years is a big milestone and deserves a good celebration. Do you
have anything to say to us? Maybe some wishes, good stories or just a happy
birthday blessing? Looking forward to your voices.

大家好！距离 HBase 成为 Apache 顶级项目 (TLP) 已经过去了整整 10 年
[1]，这是一个值得纪念的里程碑。在这个特殊的时刻，您有什么想对 HBase 说的吗？分享您和 HBase 之间发生的故事，表达您对 HBase
的期待，或者是一句简单的“生日快乐”祝福？期待听到您的声音。

Best Regards,
Yu (on behalf of the Apache HBase PMC)

祝好！
Yu (代表Apache HBase PMC)

[1] https://whimsy.apache.org/board/minutes/HBase.html#2010-04-21

[DISCUSS] Arrange Events for 10-year Anniversary

[Yu Li]

Dear all,

Since our project has reached its 10th birthday, and 10 years is definitely
a great milestone, I propose to arrange some special (virtual) events for
celebration. What comes into my mind include:

* Open threads to collect voices from our dev/user mailing list, like "what
do you want to say to HBase for its 10th birthday" (as well as our twitter
accounts maybe, if any)

* Arrange some online interviews to both PMC members and our customers.
Some of us have been in this project all the way and there must be some
good stories to tell, as well as expectations for the future.

* Join the Apache Feathercast as suggested in another thread.

* Form a blogpost to include all above events as an official celebration.

What do you think? Any other good ideas? Looking forward to more voices
(smile).

Best Regards,
Yu

[jira] [Resolved] (HBASE-16393) Improve computeHDFSBlocksDistribution

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-16393.
---
Resolution: Implemented

Closing since all sub-tasks resolved.

> Improve computeHDFSBlocksDistribution
> -
>
> Key: HBASE-16393
> URL: https://issues.apache.org/jira/browse/HBASE-16393
> Project: HBase
>  Issue Type: Improvement
>Reporter: Lijin Bin
>Assignee: Lijin Bin
>Priority: Major
> Attachments: HBASE-16393.patch
>
>
> With our cluster is big, i can see the balancer is slow from time to time. 
> And the balancer will be called on master startup, so we can see the startup 
> is slow also. 
> The first thing i think whether if we can parallel compute different region's 
> HDFSBlocksDistribution. 
> The second i think we can improve compute single region's 
> HDFSBlocksDistribution.
> When to compute a storefile's HDFSBlocksDistribution first we call 
> FileSystem#getFileStatus(path) and then 
> FileSystem#getFileBlockLocations(status, start, length), so two namenode rpc 
> call for every storefile. Instead we can use FileSystem#listLocatedStatus to 
> get a LocatedFileStatus for the information we need, so reduce the namenode 
> rpc call to one. This can speed the computeHDFSBlocksDistribution, but also 
> send out less rpc call to namenode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-16397) optimize FSRegionScanner

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-16397.
---
Resolution: Incomplete

Since there's no much information in the description, it's hard to judge 
whether the optimization planned is still valid. Thus I'm closing this long 
stalling one, please feel free to revive it if necessary [~binlijin]

> optimize FSRegionScanner
> 
>
> Key: HBASE-16397
> URL: https://issues.apache.org/jira/browse/HBASE-16397
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Lijin Bin
>Assignee: Lijin Bin
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Second release candidate for HBase 2.1.10 is available for download

[Yu Li]

Sorry for the late response due to vacation.

I could reproduce the failure by running `mvn
-Dtest=TestHFileCleaner#testHFileCleaning clean test`, and from the log I
found the root cause, simply because my username on the test machine
includes a dot, and the error message is like:
===

*2020-04-07 21:59:10,396 ERROR [dir-scan-pool1-thread-1]
mob.ManualMobMaintHFileCleaner(90): Failed to determine mob status of
'hdfs://localhost:54176/user/jueding.ly/test-data/42c5e99f-1b41-40d4-6117-394851f2bad9/archive/someHFileThatWouldBeAUUID.1586267949800
<http://jueding.ly/test-data/42c5e99f-1b41-40d4-6117-394851f2bad9/archive/someHFileThatWouldBeAUUID.1586267949800>',
keeping it just in case.java.lang.IllegalArgumentException: Illegal
character <.> at 7. Namespaces may only contain 'alphanumeric characters'
from any language and digits: jueding.ly <http://jueding.ly>*
===

It would be better if we could harden the test case, but since it indicates
no real bug, I don't think it should block the release.

Since the stably failed case is confirmed to be environment related and the
timed out cases could pass in single local run, I'm changing my vote to +1.

And to be explicit:

+1 (binding)

Checked sums and signatures: ok
Built from source: ok (8u101)
RAT check: ok (8u101)
Unit tests: ok (8u101)
Server web UI: ok, checked master/RS UI, table details page, debug dump,
metrics dump, everything looks good
Shell commands: ok (8u101), ran DDL/DML/flush/compact/split/merge_region
commands, everything looks good

Best Regards,
Yu


On Sun, 5 Apr 2020 at 15:49, 张铎(Duo Zhang)  wrote:

> Hi, Yu Li, I can not see these failures. Could you please confirm them
> again? What is the detailed failure message?
>
> Thanks.
>
> Yu Li  于2020年4月3日周五 上午10:24写道：
>
> > -1 (binding)
> >
> > Checked sums and signatures: ok
> > Built from source: ok (8u101)
> > RAT check: ok (8u101)
> > Unit tests: failed (8u101)
> > - TestHFileCleaner.testHFileCleaning failed stably and could be
> reproduced
> > by single run
> > - 6 Errors caused by test timed out of this invocation
> > path:
> >
> TestExportSnapshot.testExportWithTargetName:190->testExportFileSystemState:195->testExportFileSystemState:202->testExportFileSystemState:230
> > - Command to run the UT:
> >
> >
> >
> >
> >
> >
> >
> >
> > *  mvn -B -PrunAllTests\   -DreuseForks=false\
> >  -Dmaven.test.redirectTestOutputToFile=true\
> >  -Dsurefire.rerunFailingTestsCount=2\   -Dit.test=noItTest\
> >  -Dmaven.test.failure.ignore=true\   -Dsurefire.testFailureIgnore=true\
> >  -Dmaven.test.error.ignore=true\   test*
> >
> > Best Regards,
> > Yu
> >
> >
> > On Fri, 3 Apr 2020 at 09:53, Andrew Purtell  wrote:
> >
> > > -1 (binding)
> > >
> > > * Signature: ok
> > > * Checksum : ok
> > > * Rat check (1.8.0_232): ok
> > >- mvn clean apache-rat:check
> > > * Built from source (1.8.0_232): ok
> > >- mvn clean install -DskipTests
> > > * Unit tests pass (1.8.0_232): failed
> > >- mvn package -P runAllTests
> > >
> > > TestHRegionWithInMemoryFlush.testCheckAndMutate_WithCorrectValue 100%
> > > failure
> > >
> > >
> > >
> >
> org.apache.hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush.testCheckAndMutate_WithCorrectValue
> > >Run 1:
> > >
> > >
> >
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> > > expected: but was:
> > >Run 2:
> > >
> > >
> >
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> > > expected: but was:
> > >Run 3:
> > >
> > >
> >
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> > > expected: but was:
> > >Run 4:
> > >
> > >
> >
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> > > expected: but was:
> > >
> > > TestCanaryTool is broken, lots of these:
> > >
> > > [ERROR]   Run 2: TestCanaryTool.testReadTableTimeouts:218
> > > Argument(s) are different! Wanted:
> > > mockAppender.doAppend(
> > > 
> > > );
> > > -> at
> > >
> > >
> >
> org.apache.hadoop.hbase.tool.TestCanaryTool.testReadTableTimeouts(TestCanaryTool.java:218)
> > > Actual invocations have different arguments:
> > > mockAppender.doAppend(
> >

Re: [VOTE] Second release candidate for HBase 2.1.10 is available for download

[Yu Li]

-1 (binding)

Checked sums and signatures: ok
Built from source: ok (8u101)
RAT check: ok (8u101)
Unit tests: failed (8u101)
- TestHFileCleaner.testHFileCleaning failed stably and could be reproduced
by single run
- 6 Errors caused by test timed out of this invocation
path: 
TestExportSnapshot.testExportWithTargetName:190->testExportFileSystemState:195->testExportFileSystemState:202->testExportFileSystemState:230
- Command to run the UT:








*  mvn -B -PrunAllTests\   -DreuseForks=false\
 -Dmaven.test.redirectTestOutputToFile=true\
 -Dsurefire.rerunFailingTestsCount=2\   -Dit.test=noItTest\
 -Dmaven.test.failure.ignore=true\   -Dsurefire.testFailureIgnore=true\
 -Dmaven.test.error.ignore=true\   test*

Best Regards,
Yu


On Fri, 3 Apr 2020 at 09:53, Andrew Purtell  wrote:

> -1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_232): ok
>- mvn clean apache-rat:check
> * Built from source (1.8.0_232): ok
>- mvn clean install -DskipTests
> * Unit tests pass (1.8.0_232): failed
>- mvn package -P runAllTests
>
> TestHRegionWithInMemoryFlush.testCheckAndMutate_WithCorrectValue 100%
> failure
>
>
> org.apache.hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush.testCheckAndMutate_WithCorrectValue
>Run 1:
>
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> expected: but was:
>Run 2:
>
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> expected: but was:
>Run 3:
>
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> expected: but was:
>Run 4:
>
> TestHRegionWithInMemoryFlush>TestHRegion.testCheckAndMutate_WithCorrectValue:1986
> expected: but was:
>
> TestCanaryTool is broken, lots of these:
>
> [ERROR]   Run 2: TestCanaryTool.testReadTableTimeouts:218
> Argument(s) are different! Wanted:
> mockAppender.doAppend(
> 
> );
> -> at
>
> org.apache.hadoop.hbase.tool.TestCanaryTool.testReadTableTimeouts(TestCanaryTool.java:218)
> Actual invocations have different arguments:
> mockAppender.doAppend(
> org.apache.log4j.spi.LoggingEvent@5c21284d
> );
> Some flakes. The TestFromClientSide3 results are concerning because they
> could be a correctness issue:
>
> org.apache.hadoop.hbase.regionserver.TestRegionReplicas.null
>Run 1:
> TestRegionReplicas.testVerifySecondaryAbilityToReadWithOnFiles:476 »
> TestTimedOut
>Run 2: PASS
>
>
> org.apache.hadoop.hbase.client.TestFromClientSide3.testScanAfterDeletingSpecifiedRowV2
>Run 1: TestFromClientSide3.testScanAfterDeletingSpecifiedRowV2:253
> expected:<3> but was:<2>
>Run 2: TestFromClientSide3.testScanAfterDeletingSpecifiedRowV2:253
> expected:<3> but was:<2>
>Run 3: PASS
>
> org.apache.hadoop.hbase.master.assignment.TestRegionMoveAndAbandon.test
>Run 1: TestRegionMoveAndAbandon.test:118 » Runtime
> org.apache.hadoop.hbase.client.Ret...
>Run 2: PASS
>
>
> org.apache.hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures.testDisableTableWithFailover
>Run 1: TestMasterFailoverWithProcedures.setup:76 » IO Shutting down
>Run 2: PASS
>
>
> org.apache.hadoop.hbase.replication.regionserver.TestReplicator.testReplicatorWithErrors
>Run 1: TestReplicator.testReplicatorWithErrors:158 We did not replicate
> enough rows expected:<10> but was:<6>
>Run 2: PASS
>
>
> org.apache.hadoop.hbase.util.TestFromClientSide3WoUnsafe.testScanAfterDeletingSpecifiedRowV2
>Run 1:
>
> TestFromClientSide3WoUnsafe>TestFromClientSide3.testScanAfterDeletingSpecifiedRowV2:253
> expected:<3> but was:<2>
>Run 2:
>
> TestFromClientSide3WoUnsafe>TestFromClientSide3.testScanAfterDeletingSpecifiedRowV2:253
> expected:<3> but was:<2>
>Run 3: PASS
>
>
> On Tue, Mar 31, 2020 at 9:15 PM Duo Zhang  wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-2.1.10RC1
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.1.10
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.1.10RC1:
> >
> > https://github.com/apache/hbase/tree/2.1.10RC1
> >
> > 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.1.10RC1/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >  https://repository.apache.org/content/repositories/orgapachehbase-1387/
> >
> > Artifacts were signed with the 9AD2AE49 key which can be found in:
> >
> >  https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > 2.1.10 includes ~23 bug and improvement fixes done since the 2.1.9.
> >
> >  To learn more about apache hbase, please see
> > http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] Move stable pointer to the latest 2.2.x release

[Yu Li]

+1 for moving stable pointer to 2.2.3

Side note: I'm not sure whether adding a new stable-1 pointer is a good
idea, does it mean that "if users still don't want to go 2.x we suggest
1.4.11"? Maybe worth another thread for discussion to keep this thread on
track (smile).

Best Regards,
Yu


On Sat, 18 Jan 2020 at 21:16, Guanghao Zhang  wrote:

> +1
>
> 张铎(Duo Zhang)  于2020年1月18日周六 下午9:04写道：
>
> > OK, so let's wait for 72 hours, if no objections I will change the stable
> > pointer.
> >
> > Thanks.
> >
> > Sean Busbey  于2020年1月18日周六 上午3:14写道：
> >
> > > FWIW I don't think we need a VOTE on this; consensus has been shown
> > across
> > > several discussion threads.
> > >
> > > all the same, +1 from me.
> > >
> > > On Fri, Jan 17, 2020 at 8:42 AM Duo Zhang  wrote:
> > >
> > > > We have discussed this several times in the past, this is the most
> > recent
> > > > one
> > > >
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/f9ae2bf212d4d1c48eecf3d1d26edb0dd3d1d3bb8096bf6740839dbe%40%3Cdev.hbase.apache.org%3E
> > > >
> > > >
> > > > And seems the consensus is to move the stable pointer to 2.2.x.
> > > >
> > > > So here I want to call a vote, to officially move the stable pointer
> to
> > > > 2.2.3, and create a new stable-1 pointer to point to 1.4.11.
> > > >
> > > > The vote will last for at least 72 hours.
> > > >
> > > > Please vote
> > > >
> > > > [+1] Agree
> > > > [-1] Disagree (please include actionable feedback)
> > > >
> > > > Thanks.
> > > >
> > >
> >
>

Re: [DISCUSS] Bump hadoop versions

[Yu Li]

Looking forward to see the plan of 3.0 :-)

Best Regards,
Yu


On Sat, 4 Jan 2020 at 23:48, Sean Busbey  wrote:

> That's me. I'll update with a plan later in the week.
>
> On Sat, Jan 4, 2020, 09:02 张铎(Duo Zhang)  wrote:
>
> > Anyway if we want to start releasing 3.x alpha versions, at least we need
> > to have a release manager... Dang
> >
> > Andrew Purtell  于2020年1月4日周六 上午11:38写道：
> >
> > > Releasing HBase 3 snapshots off master would be fine by me.
> > >
> > > > On Jan 3, 2020, at 7:37 PM, Sean Busbey  wrote:
> > > >
> > > > A while back I offered to start making hbase 3 alpha releases so we
> > had
> > > > something we could all refer to in test environments. That offer
> still
> > > > stands.
> > > >
> > > >
> > > > I personally would still rather those releases be off of the master
> > > branch
> > > > because we still have too many branches given our tooling for
> > backports.
> > > >
> > > >> On Fri, Jan 3, 2020, 21:30 Andrew Purtell  >
> > > wrote:
> > > >>
> > > >> Why not start a branch-3 and begin SNAPSHOT releasing of this branch
> > > right
> > > >> now?
> > > >>
> > > >> +1 to dropping Hadoop 2 support in HBase 3. We need the major
> > increment
> > > to
> > > >> make this kind of change, let’s take the opportunity.
> > > >>
> > > >> Regarding Hadoop 2, the discussion I have seen indicates Hadoop
> thinks
> > > it
> > > >> will be releasing 2.x for up to two more years. I don’t know how
> many
> > > >> releases there will actually be but let’s assume at least one more
> > 2.9,
> > > and
> > > >> a few 2.10. My employer is expected to use these versions along a
> > > >> transition path to 3.x for at least the next eighteen months. We are
> > > >> probably typical. We won’t need Hadoop 2 support for a HBase 3 but
> > will
> > > >> need it for HBase 1 and HBase 2 for “a couple years”.
> > > >>
> > >  On Jan 3, 2020, at 6:52 PM, Sean Busbey 
> wrote:
> > > >>>
> > > >>> I personally like having Hadoop 2 support still, but I agree the
> > > cadence
> > > >>> out of Hadoop has been problematic.
> > > >>>
> > > >>> I would prefer we not change the state of Hadoop support in the
> > master
> > > >>> branch until we have a release plan of some kind for HBase 3. I'd
> > > rather
> > > >>> that be sooner rather than later.
> > > >>>
> > >  On Fri, Jan 3, 2020, 18:08 张铎(Duo Zhang) 
> > > wrote:
> > > 
> > >  Support Hadoop 2.x in 3.0.0 means we need to carry it over the
> whole
> > > 3.x
> > >  release lines, which seems to be a problem since the Hadoop
> > community
> > > do
> > >  not want to new 2.x release line any more...
> > > 
> > >  Nick Dimiduk 于2020年1月4日 周六06:55写道：
> > > 
> > > > On Wed, Dec 25, 2019 at 5:38 PM 张铎(Duo Zhang) <
> > palomino...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> We will only remove the hadoop 2.x support from hbase 3.x, which
> > > does
> > >  not
> > > >> have a formal release plan yet, for 2.x we will still support
> > hadoop
> > >  2.x.
> > > >>
> > > >
> > > > Indeed there is no formal release plan for HBase-3.0, but I hope
> > it's
> > > > sooner than 2+ years away! What's the motivation for dropping
> > Hadoop2
> > > > support?
> > > >
> > > > Wei-Chiu Chuang  于2019年12月26日周四 上午8:57写道：
> > > >>
> > > >>> With my Hadoop hat's on, we have not yet officially declared
> > Hadoop
> > >  2.8
> > > >>> EOL. I think the 2.8 download missing from the web page is
> just a
> > > >> mistake.
> > > >>>
> > > >>> That being said, some of the biggest Hadoop users (LinkedIn,
> > Yahoo,
> > > >>> Microsoft) that I am aware of are moving up from 2.7/2.8 to
> 2.10,
> > > and
> > > >> that
> > > >>> 2.8.5 (the last version in the 2.8 line) was released in Sep
> > 2018,
> > >  more
> > > >>> than a year ago. It doesn't look like the community has the
> > desire
> > > to
> > > >>> continue the 2.8 line.
> > > >>>
> > > >>> I think it is a little extreme to remove hadoop2 profile, given
> > > that
> > > >> Hadoop
> > > >>> 2.9 and 2.10 are still active and I expect Hadoop 2 to stay
> > around
> > >  for
> > > > at
> > > >>> least 2 years out.
> > > >>>
> > > >>> On Thu, Dec 26, 2019 at 8:41 AM 张铎(Duo Zhang) <
> > > palomino...@gmail.com
> > > >
> > > >>> wrote:
> > > >>>
> > >  Hadoop 2.8.x has been removed from the download page of hadoop
> > so
> > > I
> > > >> think
> > >  it is time to bump the hadoop dependency to 2.9.x, on master
> an
> > > >> branch-2.
> > > 
> > >  And the hadoop community is going to make 2.10.x the last
> minor
> > > > release
> > >  line for 2.x
> > > 
> > > 
> > > 
> > > >>>
> > > >>
> > > >
> > > 
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/cab84265d632b90d66dcd1ad957a7439a2c76a987c7e62feafb4812e%40%3Ccommon-dev.hadoop.apache.org%3E
> > > 
> > > 

[jira] [Resolved] (HBASE-21428) Performance issue due to userRegionLock in the ConnectionManager.

[Yu Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-21428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-21428.
---
Resolution: Won't Fix

Thanks for the update [~taejin], and glad to know you find a solution. I'm 
closing this issue as won't fix and linking HBASE-21196 with it.

> Performance issue due to userRegionLock in the ConnectionManager.
> -
>
> Key: HBASE-21428
> URL: https://issues.apache.org/jira/browse/HBASE-21428
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.2.7
>Reporter: koo
>Priority: Major
>
> My service is that execute a lot of puts using HTableMultiplexer.
> After the version change, most of the requests are rejected.
> It works fine in 1.2.6.1, but there is a problem in 1.2.7.
> This issue is related with the HBASE-19260.
> Most of my threads are using a lot of time as below.
>  
> |"Worker-972" #2479 daemon prio=5 os_prio=0 tid=0x7f8cea86b000 nid=0x4c8c 
> waiting on condition [0x7f8b78104000]
>  java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for <0x0005dd703b78> (a 
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
>  at 
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
>  at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>  at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1274)
>  at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1186)
>  at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1170)
>  at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1127)
>  at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.getRegionLocation(ConnectionManager.java:962)
>  at 
> org.apache.hadoop.hbase.client.HTableMultiplexer.put(HTableMultiplexer.java:206)
>  at 
> org.apache.hadoop.hbase.client.HTableMultiplexer.put(HTableMultiplexer.java:150)|
>  
> When I looked at the issue(HBASE-19260), I recognized the dangerous of to 
> allow accessessing multiple threads.
> However, Already create many threads with the limitations
> I think it is very inefficient to allow only one thread access.
>  
> | this.metaLookupPool = getThreadPool(
>  conf.getInt("hbase.hconnection.meta.lookup.threads.max", 128),
>  conf.getInt("hbase.hconnection.meta.lookup.threads.core", 10),
>  "-metaLookup-shared-", new LinkedBlockingQueue());|
>  
> I want to suggest changing it that allow to have multiple locks.(but not the 
> entire thread)
> The following is pseudocode.
>  
> |int lockSize = conf.getInt("hbase.hconnection.meta.lookup.threads.max", 128) 
> / 2;
> BlockingQueue userRegionLockQueue = new 
> LinkedBlockingQueue();
>  for (int i=0; i   userRegionLockQueue.put(new ReentrantLock());
>  }|
>  
> thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [ANNOUNCE] Please welcome Wellington Chevreuil to the Apache HBase PMC

[Yu Li]

Congratulations and welcome, Wellington!

Best Regards,
Yu


On Sun, 3 Nov 2019 at 12:02, Toshihiro Suzuki  wrote:

> Congratulations! Wellington
>
> On Sat, Nov 2, 2019 at 9:14 PM Pankaj kr  wrote:
>
> > Congratulations Wellington..!!
> >
> > Regards,
> > Pankaj
> >
> >
> > -Original Message-
> > From: Sean Busbey [mailto:bus...@apache.org]
> > Sent: 24 October 2019 01:47
> > To: dev ; Hbase-User 
> > Subject: [ANNOUNCE] Please welcome Wellington Chevreuil to the Apache
> > HBase PMC
> >
> > On behalf of the Apache HBase PMC I am pleased to announce that
> Wellington
> > Chevreuil has accepted our invitation to become a PMC member on the HBase
> > project. We appreciate Wellington stepping up to take more responsibility
> > in the HBase project.
> >
> > Please join me in welcoming Wellington to the HBase PMC!
> >
> >
> >
> > As a reminder, if anyone would like to nominate another person as a
> > committer or PMC member, even if you are not currently a committer or PMC
> > member, you can always drop a note to priv...@hbase.apache.org to let us
> > know.
> >
>

Re: [NOTICE] Reid Chan has been added to the HBASE PMC!

[Yu Li]

Congratulations, Reid!

Best Regards,
Yu


On Sat, 31 Aug 2019 at 22:58, Toshihiro Suzuki  wrote:

> Congratulations! Reid
>
> On Mon, Aug 19, 2019 at 1:53 PM Pankaj kr  wrote:
>
> > Congratulations Reid...!!
> >
> > Regards,
> > Pankaj
> >
> > -Original Message-
> > From: Stack [mailto:st...@duboce.net]
> > Sent: 16 August 2019 23:00
> > To: HBase Dev List 
> > Subject: [NOTICE] Reid Chan has been added to the HBASE PMC!
> >
> > The mighty Reid Chan has been added to the hbase PMC. A bunch of us
> > thought he was on the PMC already but on a whim, I took a look and
> noticed
> > that he wasn't. Reid Chan has been a healthy influence about the place
> > especially contributing helping new contributors getting acclimatized to
> > the ways and means of hbase contribution helping keep up standards. He's
> a
> > fabulous resource to have about the project. Letting you all know he's
> been
> > added to the PMC.
> > Yours,
> > S
> >
>

Re: [ANNOUNCE] Please welcome Zheng Hu to the HBase PMC

[Yu Li]

Congratulations and welcome, Zheng! Glad to have you on board (smile)

Best Regards,
Yu


On Tue, 6 Aug 2019 at 18:51, Tak-Lon (Stephen) Wu  wrote:

> Congratulations Zheng!
>
> -Stephen
>
> On Tue, Aug 6, 2019 at 9:01 AM Esteban Gutierrez
>  wrote:
>
> > Congrats Zheng!
> >
> > Thanks,
> > Esteban.
> >
> > --
> > Cloudera, Inc.
> >
> >
> >
> > On Tue, Aug 6, 2019 at 8:13 AM Sean Busbey  wrote:
> >
> > > Thanks for taking on these added responsibilities Zheng!
> > >
> > > On Sun, Aug 4, 2019 at 9:08 PM Duo Zhang  wrote:
> > > >
> > > > On behalf of the Apache HBase PMC I am pleased to announce that Zheng
> > Hu
> > > > has accepted our invitation to become a PMC member on the Apache
> HBase
> > > > project. We appreciate Zheng Hu stepping up to take more
> responsibility
> > > in
> > > > the HBase project.
> > > >
> > > > Please join me in welcoming Zheng Hu to the HBase PMC!
> > >
> >
>

Re: [ANNOUNCE] new HBase committer Sakthi

[Yu Li]

Congratulations Sakthi!

Best Regards,
Yu


On Fri, 2 Aug 2019 at 01:55, Sakthi  wrote:

> Thank you all, for your warm wishes. Hope to continue contributing to the
> project!
>
> Cheers,
> Sakthi
>
> On Thu, Aug 1, 2019 at 2:15 PM Zach York 
> wrote:
>
> > Congrats Sakthi! Welcome!
> >
> > On Thu, Aug 1, 2019 at 11:07 AM Jesse Yates 
> > wrote:
> >
> > > Congrats sakthi!
> > >
> > >
> > >
> > > On Thu, Aug 1, 2019 at 10:02 AM Ankit Singhal <
> ankitsingha...@gmail.com>
> > > wrote:
> > >
> > > > Congratulations Sakthi !!
> > > >
> > > > On Thu, Aug 1, 2019 at 7:15 AM Toshihiro Suzuki  >
> > > > wrote:
> > > >
> > > > > Congratulations! Sakthi
> > > > >
> > > > > On Thu, Aug 1, 2019 at 9:49 PM Guanghao Zhang 
> > > > wrote:
> > > > >
> > > > > > Congratulations!
> > > > > >
> > > > > > Allan Yang  于2019年8月1日周四 下午8:46写道：
> > > > > >
> > > > > > > Congratulations Sakthi !
> > > > > > >
> > > > > > > Best Regards
> > > > > > > Allan Yang
> > > > > > >
> > > > > > >
> > > > > > > Nihal Jain  于2019年8月1日周四 下午8:40写道：
> > > > > > >
> > > > > > > > Congrats Sakthi. More power to you!
> > > > > > > >
> > > > > > > > On Thu, 1 Aug, 2019, 4:42 PM ramkrishna vasudevan, <
> > > > > > > > ramkrishna.s.vasude...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Congratulations Sakthi !!!
> > > > > > > > >
> > > > > > > > > On Thu, Aug 1, 2019 at 3:34 PM 张铎(Duo Zhang) <
> > > > > palomino...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Congratulations!
> > > > > > > > > >
> > > > > > > > > > Pankaj kr  于2019年8月1日周四 下午5:56写道：
> > > > > > > > > >
> > > > > > > > > > > Congratulation Sakthi..!!
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Pankaj
> > > > > > > > > > >
> > > > > > > > > > > -Original Message-
> > > > > > > > > > > From: Sean Busbey [mailto:bus...@apache.org]
> > > > > > > > > > > Sent: 01 August 2019 05:35
> > > > > > > > > > > To: u...@hbase.apache.org; dev 
> > > > > > > > > > > Subject: [ANNOUNCE] new HBase committer Sakthi
> > > > > > > > > > >
> > > > > > > > > > > On behalf of the HBase PMC, I'm pleased to announce
> that
> > > > Sakthi
> > > > > > has
> > > > > > > > > > > accepted our invitation to become an HBase committer.
> > > > > > > > > > >
> > > > > > > > > > > We'd like to thank Sakthi for all of his diligent
> > > > contributions
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > project thus far. We look forward to his continued
> > > > > participation
> > > > > > in
> > > > > > > > our
> > > > > > > > > > > community.
> > > > > > > > > > >
> > > > > > > > > > > Congrats and welcome Sakthi!
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Announce] 张铎 (Duo Zhang) is Apache HBase PMC chair

[Yu Li]

Congratulations Duo! And thank you Misty!

Best Regards,
Yu


On Sun, 21 Jul 2019 at 11:21, Allan Yang  wrote:

> Congratulations Duo!
> Best Regards
> Allan Yang
>
>
> 宾莉金（binlijin）  于2019年7月21日周日 上午10:05写道：
>
> > Congratulations Duo!  and thanks Misty.
> >
> > Anoop Sam John  于2019年7月21日周日 上午9:26写道：
> >
> > > Congrats Duo.
> > >
> > > Thanks Misty for your great work as the PMC chair.
> > >
> > > Anoop
> > >
> > > On Sat, Jul 20, 2019 at 12:07 AM Xu Cang  wrote:
> > >
> > > > Thank you Misty!
> > > > Congratulations Duo, thanks for taking extra work!
> > > >
> > > > On Fri, Jul 19, 2019 at 11:23 AM Zach York <
> > zyork.contribut...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Congratulations Duo! Thanks for offering to take on the additional
> > > work!
> > > > >
> > > > > On Fri, Jul 19, 2019 at 10:34 AM Stack  wrote:
> > > > >
> > > > > > Thank you Misty for your years of service (FYI, for non-PMCers,
> the
> > > > > reports
> > > > > > Misty wrote to the Apache Board on our behalf were repeatedly
> > called
> > > > out
> > > > > > for their quality and thoughtfulness).
> > > > > >
> > > > > > Duo Zhang, thank you for taking on the mantle.
> > > > > >
> > > > > > S
> > > > > >
> > > > > > On Thu, Jul 18, 2019 at 10:46 AM Misty Linville <
> mi...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > Each Apache project has a project management committee (PMC)
> that
> > > > > > oversees
> > > > > > > governance of the project, votes on new committers and PMC
> > members,
> > > > and
> > > > > > > ensures that the software we produce adheres to the standards
> of
> > > the
> > > > > > > Foundation. One of the roles on the PMC is the PMC chair. The
> PMC
> > > > chair
> > > > > > > represents the project as a Vice President of the Foundation
> and
> > > > > > > communicates to the board about the project's health, once per
> > > > quarter
> > > > > > and
> > > > > > > at other times as needed.
> > > > > > >
> > > > > > > It's been my honor to serve as your PMC chair since 2017, when
> I
> > > took
> > > > > > over
> > > > > > > from Andrew Purtell. I've decided to step back from my
> volunteer
> > > ASF
> > > > > > > activities to leave room in my life for other things. The HBase
> > PMC
> > > > > > > nominated Duo for this role, and Duo has kindly agreed! The
> board
> > > > > passed
> > > > > > > this resolution in its meeting yesterday[1] and it is already
> > > > > > official[2].
> > > > > > > Congratulations, Duo, and thank you for continuing to honor the
> > > > project
> > > > > > > with your dedication.
> > > > > > >
> > > > > > > Misty
> > > > > > >
> > > > > > > [1] The minutes have not yet posted at the time of this email,
> > but
> > > > will
> > > > > > be
> > > > > > > available at
> > > http://www.apache.org/foundation/records/minutes/2019/.
> > > > > > > [2] https://www.apache.org/foundation/#who-runs-the-asf
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > *Best Regards,*
> >  lijin bin
> >
>

Re: [ANNOUNCE] New Committer: Wellington Chevreuil

[Yu Li]

Congratulations and welcome, Wellington.

Best Regards,
Yu


On Sun, 9 Jun 2019 at 23:19, OpenInx  wrote:

> Congratulations Wellington!
>
> On Sat, Jun 8, 2019 at 5:01 AM Xu Cang 
> wrote:
>
> > Congrats Wellington and welcome!
> >
> >
> > On Fri, Jun 7, 2019 at 1:21 PM Sakthi 
> wrote:
> >
> > > Hurray! Congrats Wellington. Well deserved one!
> > >
> > > Sakthi
> > >
> > > On Fri, Jun 7, 2019 at 12:58 PM Wei-Chiu Chuang
> > >  wrote:
> > >
> > > > Yay!! Congrats for the achievement!
> > > >
> > > > On Fri, Jun 7, 2019 at 12:56 PM Andrew Purtell <
> > andrew.purt...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Congratulations and welcome, Wellington.
> > > > >
> > > > > > On Jun 7, 2019, at 3:11 AM, Peter Somogyi 
> > > wrote:
> > > > > >
> > > > > > On behalf of the HBase PMC, I'm pleased to announce that
> Wellington
> > > > > > Chevreuil has accepted our invitation to become an HBase
> committer.
> > > > > >
> > > > > > Thanks for all your hard work Wellington; we look forward to more
> > > > > > contributions!
> > > > > >
> > > > > > Please join me in extending congratulations to Wellington!
> > > > >
> > > >
> > >
> >
>

Re: I'm about to give up on RMing

[Yu Li]

Personally when available I spent more time in branch-1 release voting than
branch-2 since I think branch-1 is still the stable pointer, also the main
usage in production. For the same reason I'm more cautious to give a +1 for
branch-1. For me a -1 is not a veto but something noticeable, while I also
agree that if I saw a -1 I will wait for RM's explanation or the next RC to
cut my own vote, so I myself will change to use +0 in future.

I share the same observation that branch-1 releases are hard to attract
votes. Probably this reflects that more users (at least PMCs) are waiting
for a stable branch-2 release for upgrading rather than a new branch-1 one?
If this is the case, then IMHO we should move our stable pointer to
branch-2 and EOL branch-1 asap. Or if users are still expecting branch-1
releases but PMC focus more on branch-2, we should figure out a way to
resolve the conflict.

I'd like to emphasize that I think you're a great RM Andrew (and I could
recall the good memories using 0.98 series in production). And I could feel
your frustration and my apology if my -1 on 1.5.0 RC is part of the reason
(although not on purpose).

Best Regards,
Yu


On Fri, 10 May 2019 at 08:59, Andrew Purtell  wrote:

> > In that regard I think we should be easier on newcomers. Old timers
> should know better and follow up with jiras.
>
> This is a fair point.
>
> I would say anyone should feel free to raise a question in the vote thread,
> or file a JIRA and mention it. I can only speak for myself but questions or
> concerns raised during a vote are not what is frustrating about RMing at
> this time. It's great to see the engagement.
>
>
> On Thu, May 9, 2019 at 5:49 PM Artem Ervits  wrote:
>
> > Andrew, I can only imagine how hard it is to be an RM, it takes me hours
> to
> > review a release let alone roll one. With so many RCs for each branch,
> it's
> > hard to focus on which branch to target and like you said volunteer time
> is
> > expensive. Sometimes for new contributors it is uncertain whether the
> > observed behavior is intentional or something to be concerned with. I
> like
> > to point those issues out on a vote and gauge the RM and other voters'
> > opinion whether it calls for jira. In that regard I think we should be
> > easier on newcomers. Old timers should know better and follow up with
> > jiras. Im guilty of calling out certain nits, case in point
> > hbase-connectors vote. [1] Luckily feedback loop was quick and we were
> able
> > to get subsequent issues fixed as part of jiras. It goes back to being
> good
> > citizen of the community, I'm happy to do reviews but maybe what we
> should
> > also do for each specific release, call out the issues to test in the
> vote
> > thread.
> >
> > That said, question I had for releases below 2.1, do we want to publish
> > client binaries [2] or is it something we want to do going forward?
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/2e94a8da7df937e9adf7dc12212ade2eb24f920bb293430e439dde5c@
> > 
> >
> > [2]
> > https://issues.apache.org/jira/plugins/servlet/mobile#issue/HBASE-19735
> >
> > On Thu, May 9, 2019, 1:42 PM Andrew Purtell  wrote:
> >
> > > Yes, I am already using that phrasing, because it is very difficult to
> > get
> > > voting interest in any 1.x release candidate. See my other response in
> > this
> > > regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large
> > > aspect of why I find it so frustrating to try and make progress with
> > these
> > > code lines. And yet we absolutely rely upon them at my place of
> > employment,
> > > so it appears we are stuck. In other discussions I've discussed why we
> > > think HBase 2 is not ready for our production yet. I am perfectly
> willing
> > > to maintain branch-1s and raise the RMs, but not if every vote is a
> slog
> > > where I'm out on the street begging for votes, and receiving vetos with
> > no
> > > assistance for the trouble. I'm pretty sure Francis is in the same
> > position
> > > with branch-1.3.
> > >
> > >
> > > On Thu, May 9, 2019 at 10:36 AM Sean Busbey  wrote:
> > >
> > > > Personally I don't think we have enough community release voting to
> > > > support having closing dates on votes. This was definitely the case
> on
> > > > 1.2 releases. IIRC it was also true fo the last 1.3 release.
> > > >
> > > > I think you're already using the "I would like to close this around
> > > > XXX" phrasing, but just in case I'm mistaken I figure I should call
> it
> > > > out.
> > > >
> > > > On Thu, May 9, 2019 at 12:32 PM Andrew Purtell 
> > > > wrote:
> > > > >
> > > > > Sure I will concede treating -1s as vetos is a contributing factor,
> > > but I
> > > > > think this is just a nod to reality. We have a hard enough time
> > > > attracting
> > > > > votes on a candidate as it is. When a -1 is cast, maybe I am
> > > > insufficiently
> > > > > optimistic, but I strongly suspect we won't get enough +1s to
> > overcome
> > > > it.
> > > > > I think that is a realistic 

Re: [DISCUSS] HBase 3

[Yu Li]

Thanks for the feedback guys, and good to know your thoughts/requirements
about ccsmap, will start scheduling for it.

I believe in-memory flush/compaction could enhance the performance, the
only concern for production is stability. Would be great if we could see it
earlier on production like in 2.3/2.4

Best Regards,
Yu


On Wed, 8 May 2019 at 15:13, Anoop John  wrote:

> > I do not think these two features can be done in 3.0.
> Fine.. I was just asking as we said cloud readiness. Fully agree to the
> concern. Might be good for 4.0
>
> Agree to other items in the list.  Ya lets try to stabilize the Compacting
> Memstore feature.  Am ready to help in that area.
>
> Anoop
>
> On Mon, May 6, 2019 at 11:05 PM Andrew Purtell 
> wrote:
>
> > Also +1 for ccsmap and this could even be useful and of reasonable risk
> to
> > be backported to a 1.6.0 (if we ever make one)
> >
> > On Mon, May 6, 2019 at 9:20 AM 张洸豪  wrote:
> >
> > > +1 for ccsmap.
> > > For in memory flush/compaction, @ZhengH tested it once. The gc time
> > > reduced a lot and p99/p999 is small and stable. We will try it on our
> > > cluster. So I thought this feature may be production ready in HBase 2.3
> > or
> > > 2.4?
> > > Another problem is about scalability. Now we have one production
> cluster
> > > which have thousands tables and hundreds of thousands regions. There
> are
> > > more than 5 Qps to meta region. We have to disable client prefetch
> to
> > > reduce the pressure of meta. So we should reconsider to enable more
> than
> > > one meta region for HBase 3.0.
> > >
> > >
> > >
> > > ---Original---
> > > From: "Sean Busbey"
> > > Date: Mon, May 6, 2019 21:06 PM
> > > To: "dev";
> > > Subject: Re: [DISCUSS] HBase 3
> > >
> > >
> > > I agree with Duo, neither of those is close to done enough for 3.0.
> > >
> > > On Mon, May 6, 2019, 06:48 张铎(Duo Zhang) 
> wrote:
> > >
> > > > I do not think these two features can be done in 3.0...
> > > >
> > > > Anoop John 于2019年5月6日 周一14:48写道：
> > > >
> > > > > For the cloud usages, we should include the new FS abstraction
> issue
> > > also
> > > > > targeted ?  What abt the WAL on Ratis?  We can fix the features
> what
> > we
> > > > > would like to see in 3.0 and then have feature freeze. So that 3.0
> > wont
> > > > > become so huge changes.
> > > > >
> > > > > Anoop
> > > > >
> > > > > On Mon, May 6, 2019 at 9:52 AM Yu Li  wrote:
> > > > >
> > > > > > TL;DR: Maybe firstly we should figure out what direction we
> should
> > > > focus
> > > > > > for 3.0? It seems to me current performance is good enough for
> most
> > > use
> > > > > > case and no longer a big concern, so more requirements are about
> > > > > stability
> > > > > > and elasticity (in cloud)? Or if anyone do have performance
> > concern,
> > > > > please
> > > > > > shout and let us know, thanks.
> > > > > >
> > > > > > All below items are performance oriented, just list out for
> > reference
> > > > > (and
> > > > > > not sure about priority from community perspective):
> > > > > > 1. CCSMap (HBASE-20312) (delayed due to job priority, sorry, but
> we
> > > > could
> > > > > > get it done if required).
> > > > > > 2. Maybe we should also target at making
> in-memory-flush/compaction
> > > > from
> > > > > > experimental to production ready?
> > > > > > 3. Server-side asynchronous (especially the write pipeline) is
> > > another
> > > > > > left-over job I ever promised to upstream but failed because the
> > > > business
> > > > > > growth on my side slows down quite a bit so it's not fully
> verified
> > > > > online
> > > > > > yet.
> > > > > >
> > > > > > Best Regards,
> > > > > > Yu
> > > > > >
> > > > > >
> > > > > > On Mon, 6 May 2019 at 06:07, Andrew Purtell  >
> > > > wrote:
> > > > > >
> > > > > > > Definitely there is value in starting this so trunk doesn't
> sink
> > > > into a
> &

Re: [ANNOUNCE] Please welcome Jan Hentschel to the Apache HBase PMC

[Yu Li]

Congratulations and welcome, Jan!

Best Regards,
Yu


On Thu, 9 May 2019 at 10:06, OpenInx  wrote:

> Congratulation, Jan! Thanks for your work.
>
> On Thu, May 9, 2019 at 6:08 AM Artem Ervits  wrote:
>
> > Well deserved Jan!
> >
> > On Wed, May 8, 2019, 5:37 PM Sean Busbey  wrote:
> >
> > > On behalf of the Apache HBase PMC I am pleased to announce that Jan
> > > Hentschel has accepted our invitation to become a PMC member on the
> > > HBase project. We appreciate Jan stepping up to take more
> > > responsibility in the HBase project.
> > >
> > > Please join me in welcoming Jan to the HBase PMC!
> > >
> > >
> > >
> > > As a reminder, if anyone would like to nominate another person as a
> > > committer or PMC member, even if you are not currently a committer or
> > > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > > let us know.
> > >
> > > -busbey
> > >
> >
>

[jira] [Resolved] (HBASE-21777) "Tune compaction throughput" debug messages even when nothing has changed

[Yu Li (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-21777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-21777.
---
Resolution: Fixed

> "Tune compaction throughput" debug messages even when nothing has changed 
> --
>
> Key: HBASE-21777
> URL: https://issues.apache.org/jira/browse/HBASE-21777
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction
>Affects Versions: 1.5.0
>Reporter: Andrew Purtell
>Assignee: Tak Lon (Stephen) Wu
>Priority: Trivial
>  Labels: branch-1
> Fix For: 3.0.0, 1.5.0, 2.2.1
>
>
> PressureAwareCompactionThroughputController will log "tune compaction 
> throughput" debug messages even when after consideration the re-tuning makes 
> no change to current settings. In that case it would be better not to log 
> anything.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-21777) "Tune compaction throughput" debug messages even when nothing has changed

[Yu Li (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-21777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-21777.
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.2.1
   3.0.0

Merged in:
master b5b89f7c
branch-2 a591c603
branch-1 fbd53bfe

Thanks [~taklwu] for contribution, and thanks [~stack] [~apurtell] [~Apache9] 
for review.

> "Tune compaction throughput" debug messages even when nothing has changed 
> --
>
> Key: HBASE-21777
> URL: https://issues.apache.org/jira/browse/HBASE-21777
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction
>Affects Versions: 1.5.0
>Reporter: Andrew Purtell
>Assignee: Tak Lon (Stephen) Wu
>Priority: Trivial
>  Labels: branch-1
> Fix For: 3.0.0, 1.5.0, 2.2.1
>
>
> PressureAwareCompactionThroughputController will log "tune compaction 
> throughput" debug messages even when after consideration the re-tuning makes 
> no change to current settings. In that case it would be better not to log 
> anything.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] HBase 3

[Yu Li]

TL;DR: Maybe firstly we should figure out what direction we should focus
for 3.0? It seems to me current performance is good enough for most use
case and no longer a big concern, so more requirements are about stability
and elasticity (in cloud)? Or if anyone do have performance concern, please
shout and let us know, thanks.

All below items are performance oriented, just list out for reference (and
not sure about priority from community perspective):
1. CCSMap (HBASE-20312) (delayed due to job priority, sorry, but we could
get it done if required).
2. Maybe we should also target at making in-memory-flush/compaction from
experimental to production ready?
3. Server-side asynchronous (especially the write pipeline) is another
left-over job I ever promised to upstream but failed because the business
growth on my side slows down quite a bit so it's not fully verified online
yet.

Best Regards,
Yu


On Mon, 6 May 2019 at 06:07, Andrew Purtell  wrote:

> Definitely there is value in starting this so trunk doesn't sink into a
> difficult to release state. Alpha releases seem fine if you want to make
> them. This assumes you'll have at least a small amount of bandwidth to run
> tests and triage any issues, though, or else any effort would be better
> spent completing the work needed to move the stable pointer to 2.x. Just my
> random advice.
>
>
> On Thu, Apr 25, 2019 at 7:55 AM Sean Busbey  wrote:
>
> > Hi folks!
> >
> > We're about a year from when HBase 2.0.0 went GA. I'd like to start
> > cutting alpha releases of 3.0.0 off of the master branch soon.
> > (expressly I do not want to create another branch, so for now anything
> > landing in master would be "in" for 3.0.0. hence the "alpha"
> > designation.)
> >
> > I was going to wait for one of the HBase 2 releases to get the stable
> > label. But lately I don't have a good sense of if that will happen
> > within a month or within six months, so I'm leaning away from waiting.
> >
> > I personally don't have a particular feature I'm trying to get out the
> > door. I just think we're at risk of another waiting-too-long for a
> > major release and want to get started on the work of quantifying
> > what's changed and figuring out how downstream projects are impacted.
> > I find that all much easier to do when there's a release artifact to
> > reference.
> >
> > I'm happy to just cut alpha releases until someone shows up with a
> > specific feature need. At that point we can come up with criteria for
> > entering and exiting beta releases.
> >
> > What do folks plan to work on getting ready that needs happen in a
> > major release?
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Yu Li]

TL;DR: I agree with Duo's proposal, that we keep the base rule in mind but
allow exceptional case with adequate discussion and fine documentation.

First of all, I'd like to express my personal appreciation for the efforts
spent on removing deprecated codes and bringing up the discussion.

Secondly, I agree with Sean that the base rule has no problem, but the real
problem is we're observing a (pretty much) slowing down on major release
period, which causes deprecated codes live for much longer than it's ought
to. Maybe it's a little bit off the track but should we start another
thread discussing about our roadmap for 3.0 or even further?

Thirdly, besides API deprecation, I think we should also discuss about the
rule for feature deprecation. We ever deprecated DLR, I could observe some
discussion on deprecating preemptive fast fail recently, and personally I
think there're some more features with few usage but making code base
complicated.

Lastly, I think we need to emphasize on adding the incompatible flag and
release note to JIRA and updating document whenever a deprecated
feature/API is removed, which IMHO is not followed quite well recently.

Thanks.

Best Regards,
Yu


On Thu, 25 Apr 2019 at 10:24, 张铎(Duo Zhang)  wrote:

> Let's get a conclusion here?
>
> By default, we should try our best to keep the deprecated APIs for at least
> a whole major release. All committers should have this in mind, when there
> is patch which deprecates a public API, we should make sure that there is
> a @deprecated javadoc comment says on which version it is deprecated, and
> on which version it is expected to be removed.
>
> And due to the difficulties in real world, if you think the above rule
> makes it really hard to maintain a clean and stable code base, you can
> break the rule. But you should have a strong enough reason, and also, a
> nice written release note, and also update the upgrading section in our ref
> guide.
>
> Is this OK?
>
> Thanks.
>
> 张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：
>
> > Phoenix is a good example I'd say, we have done a lot of CP related
> > changes before releasing 2.0.0. But until now, Phoenix still has troubles
> > to work together with 2.x, although we have already fixed several
> > compatibility issues... It shows that, usually people will take much care
> > on the alpha and beta releases...
> >
> > Reid Chan  于2019年4月24日周三 上午10:58写道：
> >
> >>
> >> As a strong coupling system to HBase, Phoenix has always been the first
> >> sufferer, not only client APIs, but also some internal APIs.
> >> Maybe we can ask Phoenix dev team what do they think, and get some
> >> thoughts from them.
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> R.C
> >>
> >>
> >>
> >> 
> >> From: Sean Busbey 
> >> Sent: 24 April 2019 10:16
> >> To: dev
> >> Subject: Re: [DISCUSS] Handling removal of deprecated methods and
> classes
> >>
> >> Isn't API stabilization what we have alpha and beta releases for?
> >>
> >> There was nearly a year between the first alpha version of 2.0.0 and the
> >> GA
> >> release. Surely that should be a reasonable window for "trying out" a
> new
> >> major release.
> >>
> >> I don't like the idea of telling our downstreamers that they can't
> >> "really"
> >> use or rely on our major releases until several minor releases in.
> Either
> >> we should say "API locks at X.0.0" or we should say "any API change
> might
> >> happen at a major version".
> >>
> >> We can always document what went away between minor releases even if we
> >> can't give a compile time warning in advance (e.g. for the 2.0.0 to
> 3.0.0
> >> user in your example Duo).
> >>
> >> We ended up trying to do that for 2.0.0 because so much had changed from
> >> 1.0.0.
> >>
> >>
> >> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) 
> wrote:
> >>
> >> > Ideally, we'd better keep the deprecated APIs for at least a whole
> major
> >> > version, that means user can upgrade to a new major release from any
> >> minor
> >> > releases, without seeing the removal of any non-deprecated APIs.
> >> >
> >> > For example, if we deprecate a method in 2.1.0, and remove it in
> 3.0.0,
> >> > then the users who upgrade to 3.0.0 from 2.0.0 will see the removal of
> >> this
> >> > method, although the method is not deprecated on 2.0.0.
> >> >
> >> > But considering the current status of our project(as Sean mentioned
> >> above),
> >> > I do not think it is a good idea to fully follow the rule. One more
> >> thing
> >> > is that, for a new major release, usually the code base is not stable
> >> > enough, need to be polished. Ideally it will be stable enough after
> one
> >> or
> >> > two minor releases. This means we will introduced new APIs and
> >> deprecated
> >> > old APIs in these minor releases. I think this is because that we do
> not
> >> > have enough test before making a new major release, but this is a dead
> >> lock
> >> > problem. If we do not publish a new major release, users 

[jira] [Resolved] (HBASE-22283) Print row and table information when failed to get region location

[Yu Li (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-22283.
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 1.5.1
   2.2.1
   3.0.0

Merged in:
master: ab3d6cf811
branch-1: 4648ab1db6
branch-2: 54b944a10f

> Print row and table information when failed to get region location
> --
>
> Key: HBASE-22283
> URL: https://issues.apache.org/jira/browse/HBASE-22283
> Project: HBase
>  Issue Type: Improvement
>  Components: Client, logging
>Affects Versions: 1.4.9, 2.0.5, 2.1.4
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Major
> Fix For: 3.0.0, 2.2.1, 1.5.1
>
>
> Currently when failed to get region location, especially when the 
> {{RegionLocations}} returned is null in 
> {{RpcRetryingCallerWithReadReplicas.getRegionLocations}} (we may see more 
> useful message if there's an exception thrown), we only log the replica id 
> w/o any detailed information about row and table, which makes the debugging 
> difficult. Below is an example error message:
> {noformat}
> Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't 
> get the location for replica 0
>   at 
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:372)
>   at 
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:153)
>   at 
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:58)
>   at 
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:219)
>   at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:277)
>   at 
> org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:438)
>   at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:312)
>   at 
> org.apache.hadoop.hbase.MetaTableAccessor.fullScan(MetaTableAccessor.java:639)
>   at 
> org.apache.hadoop.hbase.MetaTableAccessor.tableExists(MetaTableAccessor.java:366)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.tableExists(HBaseAdmin.java:409)
> {noformat}
> And here we propose to improve this part.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22283) Print row and table information when failed to get region location

[Yu Li (JIRA)]

Yu Li created HBASE-22283:
-

 Summary: Print row and table information when failed to get region 
location
 Key: HBASE-22283
 URL: https://issues.apache.org/jira/browse/HBASE-22283
 Project: HBase
  Issue Type: Improvement
  Components: Client, logging
Affects Versions: 2.1.4, 2.0.5, 1.4.9
Reporter: Yu Li
Assignee: Yu Li


Currently when failed to get region location, especially when the 
{{RegionLocations}} returned is null in 
{{RpcRetryingCallerWithReadReplicas.getRegionLocations}} (we may see more 
useful message if there's an exception thrown), we only log the replica id w/o 
any detailed information about row and table, which makes the debugging 
difficult. Below is an example error message:
{noformat}
Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get 
the location for replica 0
  at 
org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:372)
  at 
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:153)
  at 
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:58)
  at 
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:219)
  at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:277)
  at 
org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:438)
  at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:312)
  at 
org.apache.hadoop.hbase.MetaTableAccessor.fullScan(MetaTableAccessor.java:639)
  at 
org.apache.hadoop.hbase.MetaTableAccessor.tableExists(MetaTableAccessor.java:366)
  at org.apache.hadoop.hbase.client.HBaseAdmin.tableExists(HBaseAdmin.java:409)
{noformat}

And here we propose to improve this part.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

After more investigation, the ConnectionRefused exception could be
reproduced with "mvn -Dtest= test" after a complete run of all
cases through "mvn -PrunAllTests clean test", but cannot by a clean
standalone run (with "mvn *clean* test"). So now I'm more convinced it's
some kind of environment chaos caused by parallel execution of test cases,
and not a blocker issue.

@Andrew It seems to me that kerby jar is not included in our binary
package, so I'm not sure whether a new RC is required by HBASE-22219.
Anyway I'd like to revoke my -1 vote now. Thanks.

Best Regards,
Yu


On Tue, 16 Apr 2019 at 10:19, Yu Li  wrote:

> Sorry for the late response due to job priority.
>
> This ConnectionRefused issue cannot be reproduced on my laptop (MacOS
> 10.14.4) but could on the linux env. And I've checked and confirmed it
> could pass with 1.4.7/1.4.9 source package but stably failed with 1.5.0,
> performing a git bisect now, will report back later.
>
> Best Regards,
> Yu
>
>
> On Sat, 13 Apr 2019 at 00:38, Andrew Purtell 
> wrote:
>
>> I also see the occasional ConnectionRefused errors. They don’t reproduce
>> if you run the test standalone. I also only see them on a Linux dev host.
>> That may be enough to find by bisect the commit that introduced this
>> behavior. Working on it. There is a JIRA filed for this one. Search for
>> “TestBlocksRead” and label “branch-1”.
>>
>> Thanks for the investigations.
>>
>> > On Apr 12, 2019, at 6:36 AM, Yu Li  wrote:
>> >
>> > Quick updates:
>> >
>> > W/ patch of HBASE-22219 or say upgrading kerby version to 1.0.1, the
>> > failures listed above in the 1st part of hbase-server disappeared.
>> >
>> > However, in the 2nd part of hbase-server UT there're still many
>> > ConnectionRefused exceptions (17 errors in total) as shown below, which
>> > could be reproduced easily with -Dtest=xxx command on my environments,
>> > still checking the root cause.
>> >
>> > [INFO] Running org.apache.hadoop.hbase.regionserver.TestBlocksRead
>> > [ERROR] Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed:
>> > 0.853 s <<< FAILURE! - in
>> > org.apache.hadoop.hbase.regionserver.TestBlocksRead
>> > [ERROR]
>> >
>> testBlocksStoredWhenCachingDisabled(org.apache.hadoop.hbase.regionserver.TestBlocksRead)
>> > Time elapsed: 0.17 s  <<< ERROR!
>> > java.net.ConnectException: Call From
>> > z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35669 failed
>> on
>> > connection exception: java.net.ConnectException: Connection refused; For
>> > more details see:
>> > http://wiki.apache.org/hadoop/ConnectionRefused
>> >at
>> >
>> org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
>> >at
>> >
>> org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
>> > Caused by: java.net.ConnectException: Connection refused
>> >at
>> >
>> org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
>> >at
>> >
>> org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
>> >
>> > Best Regards,
>> > Yu
>> >
>> >
>> >> On Fri, 12 Apr 2019 at 13:11, Yu Li  wrote:
>> >>
>> >> I have no doubt that you've run the tests locally before announcing a
>> >> release as you're always a great RM boss. And this shows one value of
>> >> verifying release, that different voter has different environments.
>> >>
>> >> Now I think the failures may be kerberos related, since I possibly has
>> >> changed some system configuration when doing Flink testing on this env
>> >> weeks ago. Located one issue (HBASE-22219) which also observed in
>> 1.4.7,
>> >> will further investigate.
>> >>
>> >> Best Regards,
>> >> Yu
>> >>
>> >>
>> >> On Fri, 12 Apr 2019 at 12:38, Andrew Purtell > >
>> >> wrote:
>> >>
>> >>> “However it's good to find the issue earlier if there
>> >>> really is any, before release announced.”
>> >>>
>> >>> I run the complete unit test suite before announcing a release
>> candidate.
>> >>> Just to be clear.
>> >>>
>> >>> Totally agree we should get these problems sorted b

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Sorry for the late response due to job priority.

This ConnectionRefused issue cannot be reproduced on my laptop (MacOS
10.14.4) but could on the linux env. And I've checked and confirmed it
could pass with 1.4.7/1.4.9 source package but stably failed with 1.5.0,
performing a git bisect now, will report back later.

Best Regards,
Yu


On Sat, 13 Apr 2019 at 00:38, Andrew Purtell 
wrote:

> I also see the occasional ConnectionRefused errors. They don’t reproduce
> if you run the test standalone. I also only see them on a Linux dev host.
> That may be enough to find by bisect the commit that introduced this
> behavior. Working on it. There is a JIRA filed for this one. Search for
> “TestBlocksRead” and label “branch-1”.
>
> Thanks for the investigations.
>
> > On Apr 12, 2019, at 6:36 AM, Yu Li  wrote:
> >
> > Quick updates:
> >
> > W/ patch of HBASE-22219 or say upgrading kerby version to 1.0.1, the
> > failures listed above in the 1st part of hbase-server disappeared.
> >
> > However, in the 2nd part of hbase-server UT there're still many
> > ConnectionRefused exceptions (17 errors in total) as shown below, which
> > could be reproduced easily with -Dtest=xxx command on my environments,
> > still checking the root cause.
> >
> > [INFO] Running org.apache.hadoop.hbase.regionserver.TestBlocksRead
> > [ERROR] Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed:
> > 0.853 s <<< FAILURE! - in
> > org.apache.hadoop.hbase.regionserver.TestBlocksRead
> > [ERROR]
> >
> testBlocksStoredWhenCachingDisabled(org.apache.hadoop.hbase.regionserver.TestBlocksRead)
> > Time elapsed: 0.17 s  <<< ERROR!
> > java.net.ConnectException: Call From
> > z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35669 failed on
> > connection exception: java.net.ConnectException: Connection refused; For
> > more details see:
> > http://wiki.apache.org/hadoop/ConnectionRefused
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
> > Caused by: java.net.ConnectException: Connection refused
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
> >
> > Best Regards,
> > Yu
> >
> >
> >> On Fri, 12 Apr 2019 at 13:11, Yu Li  wrote:
> >>
> >> I have no doubt that you've run the tests locally before announcing a
> >> release as you're always a great RM boss. And this shows one value of
> >> verifying release, that different voter has different environments.
> >>
> >> Now I think the failures may be kerberos related, since I possibly has
> >> changed some system configuration when doing Flink testing on this env
> >> weeks ago. Located one issue (HBASE-22219) which also observed in 1.4.7,
> >> will further investigate.
> >>
> >> Best Regards,
> >> Yu
> >>
> >>
> >> On Fri, 12 Apr 2019 at 12:38, Andrew Purtell 
> >> wrote:
> >>
> >>> “However it's good to find the issue earlier if there
> >>> really is any, before release announced.”
> >>>
> >>> I run the complete unit test suite before announcing a release
> candidate.
> >>> Just to be clear.
> >>>
> >>> Totally agree we should get these problems sorted before an actual
> >>> release. My policy is to cancel a RC if anyone vetoes for this
> reason...
> >>> want as much coverage and varying environments as we can manage.
> >>>
> >>> Thank you for your help so far and I hope the failures you see result
> in
> >>> analysis and fixes that lead to better test stability.
> >>>
> >>>> On Apr 11, 2019, at 9:32 PM, Yu Li  wrote:
> >>>>
> >>>> Confirmed in 1.4.7 source the listed out cases passed (all in the 1st
> >>> part
> >>>> of hbase-server so the result comes out quickly.)... Also confirmed
> the
> >>>> test ran order are the same...
> >>>>
> >>>> Will try 1.5.0 again to prevent the environment difference caused by
> >>> time.
> >>>> If 1.5.0 still fails, will start to do the git bisect to locate the
> >>> first
> >>>> bad commit.
> >>>

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Oh one more explanation here, I meant before FORMAL release announcement,
not RC announcement, which is not a complaint.

Best Regards,
Yu


On Fri, 12 Apr 2019 at 12:38, Andrew Purtell 
wrote:

> “However it's good to find the issue earlier if there
> really is any, before release announced.”
>
> I run the complete unit test suite before announcing a release candidate.
> Just to be clear.
>
> Totally agree we should get these problems sorted before an actual
> release. My policy is to cancel a RC if anyone vetoes for this reason...
> want as much coverage and varying environments as we can manage.
>
> Thank you for your help so far and I hope the failures you see result in
> analysis and fixes that lead to better test stability.
>
> > On Apr 11, 2019, at 9:32 PM, Yu Li  wrote:
> >
> > Confirmed in 1.4.7 source the listed out cases passed (all in the 1st
> part
> > of hbase-server so the result comes out quickly.)... Also confirmed the
> > test ran order are the same...
> >
> > Will try 1.5.0 again to prevent the environment difference caused by
> time.
> > If 1.5.0 still fails, will start to do the git bisect to locate the first
> > bad commit.
> >
> > Was also expecting an easy pass and +1 as always to save time and
> efforts,
> > but obvious no luck. However it's good to find the issue earlier if there
> > really is any, before release announced.
> >
> > Best Regards,
> > Yu
> >
> >
> >> On Fri, 12 Apr 2019 at 12:16, Yu Li  wrote:
> >>
> >> Fine, let's focus on verifying whether it's a real problem rather than
> >> arguing about wording, after all that's not my intention...
> >>
> >> As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I was
> >> using the same env and all tests passed w/o issue, that's where my
> concern
> >> lies and the main reason I gave a -1 vote. I'm running against 1.4.7
> source
> >> on the same now and let's see the result.
> >>
> >> [1] https://www.mail-archive.com/dev@hbase.apache.org/msg51380.html
> >>
> >> Best Regards,
> >> Yu
> >>
> >>
> >> On Fri, 12 Apr 2019 at 12:05, Andrew Purtell 
> >> wrote:
> >>
> >>> I believe the test execution order matters. We run some tests in
> >>> parallel. The ordering of tests is determined by readdir() results and
> this
> >>> differs from host to host and checkout to checkout. So when you see a
> >>> repeatable group of failures, that’s great. And when someone else
> doesn’t
> >>> see those same tests fail, or they cannot be reproduced when running by
> >>> themselves, the commonly accepted term of art for this is “flaky”.
> >>>
> >>>
> >>>> On Apr 11, 2019, at 8:52 PM, Yu Li  wrote:
> >>>>
> >>>> Sorry but I'd call it "possible environment related problem" or "some
> >>>> feature may not work well in specific environment", rather than a
> flaky.
> >>>>
> >>>> Will check against 1.4.7 released source package before opening any
> >>> JIRA.
> >>>>
> >>>> Best Regards,
> >>>> Yu
> >>>>
> >>>>
> >>>> On Fri, 12 Apr 2019 at 11:37, Andrew Purtell <
> andrew.purt...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> And if they pass in my environment , then what should we call it
> then.
> >>> I
> >>>>> have no doubt you are seeing failures. Therefore can you please file
> >>> JIRAs
> >>>>> and attach information that can help identify a fix. Thanks.
> >>>>>
> >>>>>> On Apr 11, 2019, at 8:35 PM, Yu Li  wrote:
> >>>>>>
> >>>>>> I ran the test suite with the -Dsurefire.rerunFailingTestsCount=2
> >>> option
> >>>>>> and on two different env separately, so it sums up to 6 times stable
> >>>>>> failure for each case, and from my perspective this is not flaky.
> >>>>>>
> >>>>>> IIRC last time when verifying 1.4.7 on the same env no such issue
> >>>>> observed,
> >>>>>> will double check.
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Yu
> >>>>>>
> >>>>>>
> >>>>>> On Fri, 12 Apr 2019 at 00:07, Andrew Purtell <
> >>> andrew.purt...@gmail.com>

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Quick updates:

W/ patch of HBASE-22219 or say upgrading kerby version to 1.0.1, the
failures listed above in the 1st part of hbase-server disappeared.

However, in the 2nd part of hbase-server UT there're still many
ConnectionRefused exceptions (17 errors in total) as shown below, which
could be reproduced easily with -Dtest=xxx command on my environments,
still checking the root cause.

[INFO] Running org.apache.hadoop.hbase.regionserver.TestBlocksRead
[ERROR] Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed:
0.853 s <<< FAILURE! - in
org.apache.hadoop.hbase.regionserver.TestBlocksRead
[ERROR]
testBlocksStoredWhenCachingDisabled(org.apache.hadoop.hbase.regionserver.TestBlocksRead)
Time elapsed: 0.17 s  <<< ERROR!
java.net.ConnectException: Call From
z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35669 failed on
connection exception: java.net.ConnectException: Connection refused; For
more details see:
http://wiki.apache.org/hadoop/ConnectionRefused
at
org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
at
org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
Caused by: java.net.ConnectException: Connection refused
at
org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
at
org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)

Best Regards,
Yu


On Fri, 12 Apr 2019 at 13:11, Yu Li  wrote:

> I have no doubt that you've run the tests locally before announcing a
> release as you're always a great RM boss. And this shows one value of
> verifying release, that different voter has different environments.
>
> Now I think the failures may be kerberos related, since I possibly has
> changed some system configuration when doing Flink testing on this env
> weeks ago. Located one issue (HBASE-22219) which also observed in 1.4.7,
> will further investigate.
>
> Best Regards,
> Yu
>
>
> On Fri, 12 Apr 2019 at 12:38, Andrew Purtell 
> wrote:
>
>> “However it's good to find the issue earlier if there
>> really is any, before release announced.”
>>
>> I run the complete unit test suite before announcing a release candidate.
>> Just to be clear.
>>
>> Totally agree we should get these problems sorted before an actual
>> release. My policy is to cancel a RC if anyone vetoes for this reason...
>> want as much coverage and varying environments as we can manage.
>>
>> Thank you for your help so far and I hope the failures you see result in
>> analysis and fixes that lead to better test stability.
>>
>> > On Apr 11, 2019, at 9:32 PM, Yu Li  wrote:
>> >
>> > Confirmed in 1.4.7 source the listed out cases passed (all in the 1st
>> part
>> > of hbase-server so the result comes out quickly.)... Also confirmed the
>> > test ran order are the same...
>> >
>> > Will try 1.5.0 again to prevent the environment difference caused by
>> time.
>> > If 1.5.0 still fails, will start to do the git bisect to locate the
>> first
>> > bad commit.
>> >
>> > Was also expecting an easy pass and +1 as always to save time and
>> efforts,
>> > but obvious no luck. However it's good to find the issue earlier if
>> there
>> > really is any, before release announced.
>> >
>> > Best Regards,
>> > Yu
>> >
>> >
>> >> On Fri, 12 Apr 2019 at 12:16, Yu Li  wrote:
>> >>
>> >> Fine, let's focus on verifying whether it's a real problem rather than
>> >> arguing about wording, after all that's not my intention...
>> >>
>> >> As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I
>> was
>> >> using the same env and all tests passed w/o issue, that's where my
>> concern
>> >> lies and the main reason I gave a -1 vote. I'm running against 1.4.7
>> source
>> >> on the same now and let's see the result.
>> >>
>> >> [1] https://www.mail-archive.com/dev@hbase.apache.org/msg51380.html
>> >>
>> >> Best Regards,
>> >> Yu
>> >>
>> >>
>> >> On Fri, 12 Apr 2019 at 12:05, Andrew Purtell > >
>> >> wrote:
>> >>
>> >>> I believe the test execution order matters. We run some tests in
>> >>> parallel. The ordering of tests is determined by readdir() results
>> and this
>> >>> differs from host to host and checkout to checkout. So when you see a
>> >>> repeatable group of 

[jira] [Created] (HBASE-22225) Profiler tab on Master/RS UI not working

[Yu Li (JIRA)]

Yu Li created HBASE-5:
-

 Summary: Profiler tab on Master/RS UI not working
 Key: HBASE-5
 URL: https://issues.apache.org/jira/browse/HBASE-5
 Project: HBase
  Issue Type: Bug
  Components: master, UI
Affects Versions: 1.5.0
Reporter: Yu Li


As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler" tab 
on HMaster/RegionServer web UI, it complains page not found error like below:
{noformat}
Problem accessing /prof. Reason:
NOT_FOUND
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

I have no doubt that you've run the tests locally before announcing a
release as you're always a great RM boss. And this shows one value of
verifying release, that different voter has different environments.

Now I think the failures may be kerberos related, since I possibly has
changed some system configuration when doing Flink testing on this env
weeks ago. Located one issue (HBASE-22219) which also observed in 1.4.7,
will further investigate.

Best Regards,
Yu


On Fri, 12 Apr 2019 at 12:38, Andrew Purtell 
wrote:

> “However it's good to find the issue earlier if there
> really is any, before release announced.”
>
> I run the complete unit test suite before announcing a release candidate.
> Just to be clear.
>
> Totally agree we should get these problems sorted before an actual
> release. My policy is to cancel a RC if anyone vetoes for this reason...
> want as much coverage and varying environments as we can manage.
>
> Thank you for your help so far and I hope the failures you see result in
> analysis and fixes that lead to better test stability.
>
> > On Apr 11, 2019, at 9:32 PM, Yu Li  wrote:
> >
> > Confirmed in 1.4.7 source the listed out cases passed (all in the 1st
> part
> > of hbase-server so the result comes out quickly.)... Also confirmed the
> > test ran order are the same...
> >
> > Will try 1.5.0 again to prevent the environment difference caused by
> time.
> > If 1.5.0 still fails, will start to do the git bisect to locate the first
> > bad commit.
> >
> > Was also expecting an easy pass and +1 as always to save time and
> efforts,
> > but obvious no luck. However it's good to find the issue earlier if there
> > really is any, before release announced.
> >
> > Best Regards,
> > Yu
> >
> >
> >> On Fri, 12 Apr 2019 at 12:16, Yu Li  wrote:
> >>
> >> Fine, let's focus on verifying whether it's a real problem rather than
> >> arguing about wording, after all that's not my intention...
> >>
> >> As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I was
> >> using the same env and all tests passed w/o issue, that's where my
> concern
> >> lies and the main reason I gave a -1 vote. I'm running against 1.4.7
> source
> >> on the same now and let's see the result.
> >>
> >> [1] https://www.mail-archive.com/dev@hbase.apache.org/msg51380.html
> >>
> >> Best Regards,
> >> Yu
> >>
> >>
> >> On Fri, 12 Apr 2019 at 12:05, Andrew Purtell 
> >> wrote:
> >>
> >>> I believe the test execution order matters. We run some tests in
> >>> parallel. The ordering of tests is determined by readdir() results and
> this
> >>> differs from host to host and checkout to checkout. So when you see a
> >>> repeatable group of failures, that’s great. And when someone else
> doesn’t
> >>> see those same tests fail, or they cannot be reproduced when running by
> >>> themselves, the commonly accepted term of art for this is “flaky”.
> >>>
> >>>
> >>>> On Apr 11, 2019, at 8:52 PM, Yu Li  wrote:
> >>>>
> >>>> Sorry but I'd call it "possible environment related problem" or "some
> >>>> feature may not work well in specific environment", rather than a
> flaky.
> >>>>
> >>>> Will check against 1.4.7 released source package before opening any
> >>> JIRA.
> >>>>
> >>>> Best Regards,
> >>>> Yu
> >>>>
> >>>>
> >>>> On Fri, 12 Apr 2019 at 11:37, Andrew Purtell <
> andrew.purt...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> And if they pass in my environment , then what should we call it
> then.
> >>> I
> >>>>> have no doubt you are seeing failures. Therefore can you please file
> >>> JIRAs
> >>>>> and attach information that can help identify a fix. Thanks.
> >>>>>
> >>>>>> On Apr 11, 2019, at 8:35 PM, Yu Li  wrote:
> >>>>>>
> >>>>>> I ran the test suite with the -Dsurefire.rerunFailingTestsCount=2
> >>> option
> >>>>>> and on two different env separately, so it sums up to 6 times stable
> >>>>>> failure for each case, and from my perspective this is not flaky.
> >>>>>>
> >>>>>> IIRC last time when verifying 1.4.7 on the same env no such issue
> >>>>> observed,
> >>&

[jira] [Created] (HBASE-22219) Backport HBASE-19049 to branch-1 to prevent DIRKRB-613

[Yu Li (JIRA)]

Yu Li created HBASE-22219:
-

 Summary: Backport HBASE-19049 to branch-1 to prevent DIRKRB-613 
 Key: HBASE-22219
 URL: https://issues.apache.org/jira/browse/HBASE-22219
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 1.4.9, 1.4.7, 1.4.8
Reporter: Yu Li
Assignee: Yu Li
 Fix For: 1.5.0


Observed several UT failures when verifying 1.5.0 release, one of which is as 
follows:
{noformat}
[ERROR] org.apache.hadoop.hbase.http.TestSpnegoHttpServer  Time elapsed: 0.005 
s  <<< ERROR!
java.lang.RuntimeException: Unable to parse:includedir /etc/krb5.conf.d/
at 
org.apache.hadoop.hbase.http.TestSpnegoHttpServer.buildMiniKdc(TestSpnegoHttpServer.java:143)
at 
org.apache.hadoop.hbase.http.TestSpnegoHttpServer.setupServer(TestSpnegoHttpServer.java:91)
{noformat}

And this is a known issue of kerby 1.0.0-RC2 as indicated by DIRKRB-613 and 
fixed in 1.0.0 release (by [this 
commit|https://github.com/apache/directory-kerby/commit/e34b1ef8fec64e89780aec37aac903d4608e215f])

Thus we should backport HBASE-19049 which upgrade kerby dependency from 
1.0.0-RC2 to 1.0.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Confirmed in 1.4.7 source the listed out cases passed (all in the 1st part
of hbase-server so the result comes out quickly.)... Also confirmed the
test ran order are the same...

Will try 1.5.0 again to prevent the environment difference caused by time.
If 1.5.0 still fails, will start to do the git bisect to locate the first
bad commit.

Was also expecting an easy pass and +1 as always to save time and efforts,
but obvious no luck. However it's good to find the issue earlier if there
really is any, before release announced.

Best Regards,
Yu


On Fri, 12 Apr 2019 at 12:16, Yu Li  wrote:

> Fine, let's focus on verifying whether it's a real problem rather than
> arguing about wording, after all that's not my intention...
>
> As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I was
> using the same env and all tests passed w/o issue, that's where my concern
> lies and the main reason I gave a -1 vote. I'm running against 1.4.7 source
> on the same now and let's see the result.
>
> [1] https://www.mail-archive.com/dev@hbase.apache.org/msg51380.html
>
> Best Regards,
> Yu
>
>
> On Fri, 12 Apr 2019 at 12:05, Andrew Purtell 
> wrote:
>
>> I believe the test execution order matters. We run some tests in
>> parallel. The ordering of tests is determined by readdir() results and this
>> differs from host to host and checkout to checkout. So when you see a
>> repeatable group of failures, that’s great. And when someone else doesn’t
>> see those same tests fail, or they cannot be reproduced when running by
>> themselves, the commonly accepted term of art for this is “flaky”.
>>
>>
>> > On Apr 11, 2019, at 8:52 PM, Yu Li  wrote:
>> >
>> > Sorry but I'd call it "possible environment related problem" or "some
>> > feature may not work well in specific environment", rather than a flaky.
>> >
>> > Will check against 1.4.7 released source package before opening any
>> JIRA.
>> >
>> > Best Regards,
>> > Yu
>> >
>> >
>> > On Fri, 12 Apr 2019 at 11:37, Andrew Purtell 
>> > wrote:
>> >
>> >> And if they pass in my environment , then what should we call it then.
>> I
>> >> have no doubt you are seeing failures. Therefore can you please file
>> JIRAs
>> >> and attach information that can help identify a fix. Thanks.
>> >>
>> >>> On Apr 11, 2019, at 8:35 PM, Yu Li  wrote:
>> >>>
>> >>> I ran the test suite with the -Dsurefire.rerunFailingTestsCount=2
>> option
>> >>> and on two different env separately, so it sums up to 6 times stable
>> >>> failure for each case, and from my perspective this is not flaky.
>> >>>
>> >>> IIRC last time when verifying 1.4.7 on the same env no such issue
>> >> observed,
>> >>> will double check.
>> >>>
>> >>> Best Regards,
>> >>> Yu
>> >>>
>> >>>
>> >>> On Fri, 12 Apr 2019 at 00:07, Andrew Purtell <
>> andrew.purt...@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> There are two failure cases it looks like. And this looks like
>> flakes.
>> >>>>
>> >>>> The wrong FS assertions are not something I see when I run these
>> tests
>> >>>> myself. I am not able to investigate something I can’t reproduce.
>> What I
>> >>>> suggest is since you can reproduce do a git bisect to find the commit
>> >> that
>> >>>> introduced the problem. Then we can revert it. As an alternative we
>> can
>> >>>> open a JIRA, report the problem, temporarily @ignore the test, and
>> >>>> continue. This latter option only should be done if we are fairly
>> >> confident
>> >>>> it is a test only problem.
>> >>>>
>> >>>> The connect exceptions are interesting. I see these sometimes when
>> the
>> >>>> suite is executed, not this particular case, but when the failed
>> test is
>> >>>> executed by itself it always passes. It is possible some change to
>> >> classes
>> >>>> related to the minicluster or startup or shutdown timing are the
>> cause,
>> >> but
>> >>>> it is test time flaky behavior. I’m not happy about this but it
>> doesn’t
>> >>>> actually fail the release because the failure is never repeatable
>> when
>> >> the
>> >

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Fine, let's focus on verifying whether it's a real problem rather than
arguing about wording, after all that's not my intention...

As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I was
using the same env and all tests passed w/o issue, that's where my concern
lies and the main reason I gave a -1 vote. I'm running against 1.4.7 source
on the same now and let's see the result.

[1] https://www.mail-archive.com/dev@hbase.apache.org/msg51380.html

Best Regards,
Yu


On Fri, 12 Apr 2019 at 12:05, Andrew Purtell 
wrote:

> I believe the test execution order matters. We run some tests in parallel.
> The ordering of tests is determined by readdir() results and this differs
> from host to host and checkout to checkout. So when you see a repeatable
> group of failures, that’s great. And when someone else doesn’t see those
> same tests fail, or they cannot be reproduced when running by themselves,
> the commonly accepted term of art for this is “flaky”.
>
>
> > On Apr 11, 2019, at 8:52 PM, Yu Li  wrote:
> >
> > Sorry but I'd call it "possible environment related problem" or "some
> > feature may not work well in specific environment", rather than a flaky.
> >
> > Will check against 1.4.7 released source package before opening any JIRA.
> >
> > Best Regards,
> > Yu
> >
> >
> > On Fri, 12 Apr 2019 at 11:37, Andrew Purtell 
> > wrote:
> >
> >> And if they pass in my environment , then what should we call it then. I
> >> have no doubt you are seeing failures. Therefore can you please file
> JIRAs
> >> and attach information that can help identify a fix. Thanks.
> >>
> >>> On Apr 11, 2019, at 8:35 PM, Yu Li  wrote:
> >>>
> >>> I ran the test suite with the -Dsurefire.rerunFailingTestsCount=2
> option
> >>> and on two different env separately, so it sums up to 6 times stable
> >>> failure for each case, and from my perspective this is not flaky.
> >>>
> >>> IIRC last time when verifying 1.4.7 on the same env no such issue
> >> observed,
> >>> will double check.
> >>>
> >>> Best Regards,
> >>> Yu
> >>>
> >>>
> >>> On Fri, 12 Apr 2019 at 00:07, Andrew Purtell  >
> >>> wrote:
> >>>
> >>>> There are two failure cases it looks like. And this looks like flakes.
> >>>>
> >>>> The wrong FS assertions are not something I see when I run these tests
> >>>> myself. I am not able to investigate something I can’t reproduce.
> What I
> >>>> suggest is since you can reproduce do a git bisect to find the commit
> >> that
> >>>> introduced the problem. Then we can revert it. As an alternative we
> can
> >>>> open a JIRA, report the problem, temporarily @ignore the test, and
> >>>> continue. This latter option only should be done if we are fairly
> >> confident
> >>>> it is a test only problem.
> >>>>
> >>>> The connect exceptions are interesting. I see these sometimes when the
> >>>> suite is executed, not this particular case, but when the failed test
> is
> >>>> executed by itself it always passes. It is possible some change to
> >> classes
> >>>> related to the minicluster or startup or shutdown timing are the
> cause,
> >> but
> >>>> it is test time flaky behavior. I’m not happy about this but it
> doesn’t
> >>>> actually fail the release because the failure is never repeatable when
> >> the
> >>>> test is run standalone.
> >>>>
> >>>> In general it would be great if some attention was paid to test
> >>>> cleanliness on branch-1. As RM I’m not in a position to insist that
> >>>> everything is perfect or there will never be another 1.x release,
> >> certainly
> >>>> not from branch-1. So, tests which fail repeatedly block a release
> IMHO
> >> but
> >>>> flakes do not.
> >>>>
> >>>>
> >>>>> On Apr 10, 2019, at 11:20 PM, Yu Li  wrote:
> >>>>>
> >>>>> -1
> >>>>>
> >>>>> Observed many UT failures when checking the source package (tried
> >>>> multiple
> >>>>> rounds on two different environments, MacOs and Linux, got the same
> >>>>> result), including (but not limited to):
> >>>>>
> >>>>> TestBulkload:
> >>>>&g

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

I ran the test suite with the -Dsurefire.rerunFailingTestsCount=2 option
and on two different env separately, so it sums up to 6 times stable
failure for each case, and from my perspective this is not flaky.

IIRC last time when verifying 1.4.7 on the same env no such issue observed,
will double check.

Best Regards,
Yu


On Fri, 12 Apr 2019 at 00:07, Andrew Purtell 
wrote:

> There are two failure cases it looks like. And this looks like flakes.
>
> The wrong FS assertions are not something I see when I run these tests
> myself. I am not able to investigate something I can’t reproduce. What I
> suggest is since you can reproduce do a git bisect to find the commit that
> introduced the problem. Then we can revert it. As an alternative we can
> open a JIRA, report the problem, temporarily @ignore the test, and
> continue. This latter option only should be done if we are fairly confident
> it is a test only problem.
>
> The connect exceptions are interesting. I see these sometimes when the
> suite is executed, not this particular case, but when the failed test is
> executed by itself it always passes. It is possible some change to classes
> related to the minicluster or startup or shutdown timing are the cause, but
> it is test time flaky behavior. I’m not happy about this but it doesn’t
> actually fail the release because the failure is never repeatable when the
> test is run standalone.
>
> In general it would be great if some attention was paid to test
> cleanliness on branch-1. As RM I’m not in a position to insist that
> everything is perfect or there will never be another 1.x release, certainly
> not from branch-1. So, tests which fail repeatedly block a release IMHO but
> flakes do not.
>
>
> > On Apr 10, 2019, at 11:20 PM, Yu Li  wrote:
> >
> > -1
> >
> > Observed many UT failures when checking the source package (tried
> multiple
> > rounds on two different environments, MacOs and Linux, got the same
> > result), including (but not limited to):
> >
> > TestBulkload:
> >
> shouldBulkLoadSingleFamilyHLog(org.apache.hadoop.hbase.regionserver.TestBulkLoad)
> > Time elapsed: 0.083 s  <<< ERROR!
> > java.lang.IllegalArgumentException: Wrong FS:
> >
> file:/var/folders/t6/vch4nh357f98y1wlq09lbm7hgn/T/junit1805329913454564189/junit8020757893576011944/data/default/shouldBulkLoadSingleFamilyHLog/8f4a6b584533de2fd1bf3c398dfaac29,
> > expected: hdfs://localhost:55938
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBulkLoad.testRegionWithFamiliesAndSpecifiedTableName(TestBulkLoad.java:246)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBulkLoad.testRegionWithFamilies(TestBulkLoad.java:256)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBulkLoad.shouldBulkLoadSingleFamilyHLog(TestBulkLoad.java:150)
> >
> > TestStoreFile:
> >
> testCacheOnWriteEvictOnClose(org.apache.hadoop.hbase.regionserver.TestStoreFile)
> > Time elapsed: 0.083 s  <<< ERROR!
> > java.net.ConnectException: Call From localhost/127.0.0.1 to
> localhost:55938
> > failed on connection exception: java.net.ConnectException: Connection
> > refused; For more details see:
> > http://wiki.apache.org/hadoop/ConnectionRefused
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestStoreFile.writeStoreFile(TestStoreFile.java:1047)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestStoreFile.testCacheOnWriteEvictOnClose(TestStoreFile.java:908)
> >
> > TestHFile:
> > testEmptyHFile(org.apache.hadoop.hbase.io.hfile.TestHFile)  Time elapsed:
> > 0.08 s  <<< ERROR!
> > java.net.ConnectException: Call From
> > z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35529 failed on
> > connection exception: java.net.ConnectException: Connection refused; For
> > more details see:  http://wiki.apache.org/hadoop/ConnectionRefused
> >at
> > org.apache.hadoop.hbase.io
> .hfile.TestHFile.testEmptyHFile(TestHFile.java:90)
> > Caused by: java.net.ConnectException: Connection refused
> >at
> > org.apache.hadoop.hbase.io
> .hfile.TestHFile.testEmptyHFile(TestHFile.java:90)
> >
> > TestBlocksScanned:
> >
> testBlocksScannedWithEncoding(org.apache.hadoop.hbase.regionserver.TestBlocksScanned)
> > Time elapsed: 0.069 s  <<< ERROR!
> > java.lang.IllegalArgumentException: Wrong FS: hdfs://localhost:35529/tmp/
> >
> hbase-jueding.ly/hbase/data/default/TestBlocksScannedWithEncoding/a4a416cc3060d9820a621c294af0aa08
> ,
> > expected: file:///
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksScanned._testBlocksScann

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

-1

Observed many UT failures when checking the source package (tried multiple
rounds on two different environments, MacOs and Linux, got the same
result), including (but not limited to):

TestBulkload:
shouldBulkLoadSingleFamilyHLog(org.apache.hadoop.hbase.regionserver.TestBulkLoad)
Time elapsed: 0.083 s  <<< ERROR!
java.lang.IllegalArgumentException: Wrong FS:
file:/var/folders/t6/vch4nh357f98y1wlq09lbm7hgn/T/junit1805329913454564189/junit8020757893576011944/data/default/shouldBulkLoadSingleFamilyHLog/8f4a6b584533de2fd1bf3c398dfaac29,
expected: hdfs://localhost:55938
at
org.apache.hadoop.hbase.regionserver.TestBulkLoad.testRegionWithFamiliesAndSpecifiedTableName(TestBulkLoad.java:246)
at
org.apache.hadoop.hbase.regionserver.TestBulkLoad.testRegionWithFamilies(TestBulkLoad.java:256)
at
org.apache.hadoop.hbase.regionserver.TestBulkLoad.shouldBulkLoadSingleFamilyHLog(TestBulkLoad.java:150)

TestStoreFile:
testCacheOnWriteEvictOnClose(org.apache.hadoop.hbase.regionserver.TestStoreFile)
Time elapsed: 0.083 s  <<< ERROR!
java.net.ConnectException: Call From localhost/127.0.0.1 to localhost:55938
failed on connection exception: java.net.ConnectException: Connection
refused; For more details see:
http://wiki.apache.org/hadoop/ConnectionRefused
at
org.apache.hadoop.hbase.regionserver.TestStoreFile.writeStoreFile(TestStoreFile.java:1047)
at
org.apache.hadoop.hbase.regionserver.TestStoreFile.testCacheOnWriteEvictOnClose(TestStoreFile.java:908)

TestHFile:
testEmptyHFile(org.apache.hadoop.hbase.io.hfile.TestHFile)  Time elapsed:
0.08 s  <<< ERROR!
java.net.ConnectException: Call From
z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35529 failed on
connection exception: java.net.ConnectException: Connection refused; For
more details see:  http://wiki.apache.org/hadoop/ConnectionRefused
at
org.apache.hadoop.hbase.io.hfile.TestHFile.testEmptyHFile(TestHFile.java:90)
Caused by: java.net.ConnectException: Connection refused
at
org.apache.hadoop.hbase.io.hfile.TestHFile.testEmptyHFile(TestHFile.java:90)

TestBlocksScanned:
testBlocksScannedWithEncoding(org.apache.hadoop.hbase.regionserver.TestBlocksScanned)
Time elapsed: 0.069 s  <<< ERROR!
java.lang.IllegalArgumentException: Wrong FS: hdfs://localhost:35529/tmp/
hbase-jueding.ly/hbase/data/default/TestBlocksScannedWithEncoding/a4a416cc3060d9820a621c294af0aa08,
expected: file:///
at
org.apache.hadoop.hbase.regionserver.TestBlocksScanned._testBlocksScanned(TestBlocksScanned.java:90)
at
org.apache.hadoop.hbase.regionserver.TestBlocksScanned.testBlocksScannedWithEncoding(TestBlocksScanned.java:86)

And please let me know if any known issue I'm not aware of. Thanks.

Best Regards,
Yu


On Mon, 8 Apr 2019 at 11:38, Yu Li  wrote:

> The performance report LGTM, thanks! (and sorry for the lag due to
> Qingming Festival Holiday here in China)
>
> Still verifying the release, just some quick feedback: observed some
> incompatible changes in compatibility report including
> HBASE-21492/HBASE-21684 and worth a reminder in ReleaseNote.
>
> Irrelative but noticeable: the 1.4.9 release note URL is invalid on
> https://hbase.apache.org/downloads.html
>
> Best Regards,
> Yu
>
>
> On Fri, 5 Apr 2019 at 08:45, Andrew Purtell  wrote:
>
>> The difference is basically noise per the usual YCSB evaluation. Small
>> differences in workloads D and F (slightly worse) and workload E (slightly
>> better) that do not indicate serious regression.
>>
>> Linux version 4.14.55-62.37.amzn1.x86_64
>> c3.8xlarge x 5
>> OpenJDK Runtime Environment (build 1.8.0_181-shenandoah-b13)
>> -Xms20g -Xmx20g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+UseNUMA
>> -XX:-UseBiasedLocking -XX:+ParallelRefProcEnabled
>> Hadoop 2.9.2
>> Init: Load 100 M rows and snapshot
>> Run: Delete table, clone and redeploy from snapshot, run 10 M operations
>> Args: -threads 100 -target 5
>> Test table: {NAME => 'u', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY
>> => 'false', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING =>
>> 'ROW_INDEX_V1', TTL => 'FOREVER', COMPRESSION => 'SNAPPY', MIN_VERSIONS =>
>> '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE =>
>> '0'}
>>
>>
>> YCSB Workload A
>>
>> target 50k/op/s 1.4.9 1.5.0
>>
>>
>>
>> [OVERALL], RunTime(ms) 200592 200583
>> [OVERALL], Throughput(ops/sec) 49852 49855
>> [READ], AverageLatency(us) 544 559
>> [READ], MinLatency(us) 267 292
>> [READ], MaxLatency(us) 165631 185087
>> [READ], 95thPercentileLatency(us) 738 742
>> [READ], 99thPercentileLatency(us), 1877 1961
>> [UPDATE], AverageLatency(us) 1370 1181
>> [UPDATE], MinLatency(us) 702 646
>> 

Re: hbase contributor

[Yu Li]

Granted. Enjoy your journey in hbase project and looking forward to your
contribution (smile).

Best Regards,
Yu


On Tue, 9 Apr 2019 at 13:19, 刘文文  wrote:

> Hi,
>   I want to contribute to Apache HBase. Would you please give me the
> contributor permission? My JIRA ID is wen.feiyi.

Re: 申请 JIRA Contributor 权限

[Yu Li]

Granted. Enjoy your journey in hbase project and looking forward to your
contribution (smile).

Best Regards,
Yu


On Tue, 9 Apr 2019 at 10:43, 郭康康  wrote:

> Hi,
>
> I want to contribute to Apache HBase.
> Would you please give me the contributor permission?
> My JIRA ID is gk_coder.
>
>

Re: [DISCUSS] EOL for branch-1.2

[Yu Li]

+1

Best Regards,
Yu


On Mon, 8 Apr 2019 at 11:28, Allan Yang  wrote:

> +1
> Best Regards
> Allan Yang
>
>
> Stack  于2019年4月8日周一 上午1:43写道：
>
> > +1
> > Stack
> >
> > On Fri, Apr 5, 2019 at 6:35 PM Sean Busbey  wrote:
> >
> > > Hi folks!
> > >
> > > Back when our stable pointer first moved off of branch-1.2 releases I
> > > said I'd do ~6 months of releases[1]. I'm preparing an RC for the
> > > 1.2.12 release[2] and it's been ~6.5 months.
> > >
> > > I intend 1.2.12 to be the last release I manage off of branch-1.2. If
> > > anyone else sees a reason to keep this release line going and is
> > > willing to step in as RM please speak up.
> > >
> > > This is the template for the notice that's been in the ANNOUNCE emails
> > > for 1.2.7 - 1.2.11:
> > >
> > > > All users of previous 1.2.z releases are encouraged to upgrade to
> > either
> > > > this release or the latest in our stable release line, which is
> > currently
> > > > X.Y.Z. Releases in the 1.2.z line are expected to stop in late spring
> > > 2019.
> > >
> > >
> > > Presuming no one wants to keep things going by the time a 1.2.12 VOTE
> > > passes, I'll modify it to say the branch is EOL. About a month later
> > > I'll do a dedicated EOL post to user@hbase, clean up project
> > > references to the release line, and then remove the release from
> > > dist.apache.org (it will remain along with all the others on
> > > archive.apache.org).
> > >
> > > [1]: https://s.apache.org/UEPy
> > > [2]: https://issues.apache.org/jira/browse/HBASE-22171
> > >
> >
>

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

The performance report LGTM, thanks! (and sorry for the lag due to Qingming
Festival Holiday here in China)

Still verifying the release, just some quick feedback: observed some
incompatible changes in compatibility report including
HBASE-21492/HBASE-21684 and worth a reminder in ReleaseNote.

Irrelative but noticeable: the 1.4.9 release note URL is invalid on
https://hbase.apache.org/downloads.html

Best Regards,
Yu


On Fri, 5 Apr 2019 at 08:45, Andrew Purtell  wrote:

> The difference is basically noise per the usual YCSB evaluation. Small
> differences in workloads D and F (slightly worse) and workload E (slightly
> better) that do not indicate serious regression.
>
> Linux version 4.14.55-62.37.amzn1.x86_64
> c3.8xlarge x 5
> OpenJDK Runtime Environment (build 1.8.0_181-shenandoah-b13)
> -Xms20g -Xmx20g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+UseNUMA
> -XX:-UseBiasedLocking -XX:+ParallelRefProcEnabled
> Hadoop 2.9.2
> Init: Load 100 M rows and snapshot
> Run: Delete table, clone and redeploy from snapshot, run 10 M operations
> Args: -threads 100 -target 5
> Test table: {NAME => 'u', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY
> => 'false', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING =>
> 'ROW_INDEX_V1', TTL => 'FOREVER', COMPRESSION => 'SNAPPY', MIN_VERSIONS =>
> '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE =>
> '0'}
>
>
> YCSB Workload A
>
> target 50k/op/s 1.4.9 1.5.0
>
>
>
> [OVERALL], RunTime(ms) 200592 200583
> [OVERALL], Throughput(ops/sec) 49852 49855
> [READ], AverageLatency(us) 544 559
> [READ], MinLatency(us) 267 292
> [READ], MaxLatency(us) 165631 185087
> [READ], 95thPercentileLatency(us) 738 742
> [READ], 99thPercentileLatency(us), 1877 1961
> [UPDATE], AverageLatency(us) 1370 1181
> [UPDATE], MinLatency(us) 702 646
> [UPDATE], MaxLatency(us) 180735 177279
> [UPDATE], 95thPercentileLatency(us) 1943 1652
> [UPDATE], 99thPercentileLatency(us) 3257 3085
>
> YCSB Workload B
>
> target 50k/op/s 1.4.9 1.5.0
>
>
>
> [OVERALL], RunTime(ms) 200599 200581
> [OVERALL], Throughput(ops/sec) 49850 49855
> [READ], AverageLatency(us),  454 471
> [READ], MinLatency(us) 203 213
> [READ], MaxLatency(us) 183423 174207
> [READ], 95thPercentileLatency(us) 563 599
> [READ], 99thPercentileLatency(us) 1360 1172
> [UPDATE], AverageLatency(us) 1064 1029
> [UPDATE], MinLatency(us) 746 726
> [UPDATE], MaxLatency(us) 163455 101631
> [UPDATE], 95thPercentileLatency(us) 1327 1157
> [UPDATE], 99thPercentileLatency(us) 2241 1898
>
> YCSB Workload C
>
> target 50k/op/s 1.4.9 1.5.0
>
>
>
> [OVERALL], RunTime(ms) 200541 200538
> [OVERALL], Throughput(ops/sec) 49865 49865
> [READ], AverageLatency(us) 332 327
> [READ], MinLatency(us) 175 179
> [READ], MaxLatency(us) 210559 170367
> [READ], 95thPercentileLatency(us) 410 396
> [READ], 99thPercentileLatency(us) 871 892
>
> YCSB Workload D
>
> target 50k/op/s 1.4.9 1.5.0
>
>
>
> [OVERALL], RunTime(ms) 200579 200562
> [OVERALL], Throughput(ops/sec) 49855 49859
> [READ], AverageLatency(us) 487 547
> [READ], MinLatency(us) 210 214
> [READ], MaxLatency(us) 192255 177535
> [READ], 95thPercentileLatency(us) 973 1529
> [READ], 99thPercentileLatency(us) 1836 2683
> [INSERT], AverageLatency(us) 1239 1152
> [INSERT], MinLatency(us) 807 788
> [INSERT], MaxLatency(us) 184575 148735
> [INSERT], 95thPercentileLatency(us) 1496 1243
> [INSERT], 99thPercentileLatency(us) 2965 2495
>
> YCSB Workload E
>
> target 10k/op/s 1.4.9 1.5.0
>
>
>
> [OVERALL], RunTime(ms) 100605 100568
> [OVERALL], Throughput(ops/sec) 9939 9943
> [SCAN], AverageLatency(us) 3548 2687
> [SCAN], MinLatency(us) 696 678
> [SCAN], MaxLatency(us) 1059839 238463
> [SCAN], 95thPercentileLatency(us) 8327 6791
> [SCAN], 99thPercentileLatency(us) 17647 14415
> [INSERT], AverageLatency(us) 2688 1555
> [INSERT], MinLatency(us) 887 815
> [INSERT], MaxLatency(us) 173311 154623
> [INSERT], 95thPercentileLatency(us) 4455 2571
> [INSERT], 99thPercentileLatency(us) 9303 5375
>
> YCSB Workload F
>
> target 50k/op/s 1.4.9 1.5.0
>
>
>
> [OVERALL], RunTime(ms) 200562 204178
> [OVERALL], Throughput(ops/sec) 49859 48976
> [READ], AverageLatency(us) 856 1137
> [READ], MinLatency(us) 262 257
> [READ], MaxLatency(us) 205567 222335
> [READ], 95thPercentileLatency(us) 2365 3475
> [READ], 99thPercentileLatency(us) 3099 4143
> [READ-MODIFY-WRITE], AverageLatency(us) 2559 2917
> [READ-MODIFY-WRITE], MinLatency(us) 1100 1034
> [READ-MODIFY-WRITE], MaxLatency(us) 208767 204799
> [READ-MODIFY-WRITE], 95thPercentileLatency(us) 5747 7627
> [READ-MODIFY-WRITE], 99thPercentileLatency(us) 7203 8919
> [UPDATE], 

Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Thanks for the efforts boss.

Since it's a new minor release, do we have performance comparison report
with 1.4.9 as we did when releasing 1.4.0? If so, any reference? Many
thanks!

Best Regards,
Yu


On Thu, 4 Apr 2019 at 07:44, Andrew Purtell  wrote:

> The fourth HBase 1.5.0 release candidate (RC3) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0RC3/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1292/
>
> The git tag corresponding to the candidate is '1.5.0RC3’ (b0bc7225c5).
>
> A detailed source and binary compatibility report for this release is
> available for your review at
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0RC3/compat-check-report.html
> .
>
> A list of the 115 issues resolved in this release can be found at
> https://s.apache.org/K4Wk . The 1.5.0 changelog is derived from the
> changelog of the last branch-1.4 release, 1.4.9.
>
> Please try out the candidate and vote +1/0/-1.
>
> The vote will be open for at least 72 hours. Unless objection I will try to
> close it Friday April 12, 2019 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
> RAT check passes (7u80)
> Unit test suite passes (7u80, 8u181)*
> Opened the UI in a browser, poked around
> LTT load 100M rows with 100% verification and 20% updates (8u181)
> ITBLL 1B rows with slowDeterministic monkey (8u181)
> ITBLL 1B rows with serverKilling monkey (8u181)
>
> There are known flaky tests. See HBASE-21904 and HBASE-21905. These flaky
> tests do not represent serious test failures that would prevent a release.
>
>
> --
> Best regards,
> Andrew
>

Re: [VOTE] HBase Thirdparty 2.2.0 RC1

[Yu Li]

+1 (binding)

Checked sigs and sums: OK
Built from src: OK

Minor:
>From dev_files/make_rc.sh we are using "git archive" instead of "maven
package assembly:single", thus producing more files as listed below. Is
this on purpose? Thanks.
hbase-thirdparty-2.2.0/.gitignore
hbase-thirdparty-2.2.0/dev_files/make_rc.sh

Best Regards,
Yu


On Sun, 31 Mar 2019 at 05:14, Stack  wrote:

> Please consider the following as the 2.2.0 release of Apache HBase
> Thirdparty. It is the second release candidate for your consideration.
>
> It is a year since our 2.1.0 release. 2.2.0 updates some of our core
> dependencies:
>
>  gson 2.8.1 -> 2.8.5
>  guava 22.0 -> 27.1-jre
>  pb 3.5.1 -> 3.7.0
>  netty 4.1.17 -> 4.1.34
>  commons-collections4 4.1 -> 4.3
>
> The coming hbase-2.2.0 RC would like to include an updated
> hbase-thirdparty.
>
> Source artifact, signatures, checksums, and changes are available at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdparty/hbase-thirdparty-2.2.0RC1/
>
> The release was made against tag 2.2.0RC0. It was signed with my key
> 'st...@duboce.net' which can be found here:
>
>  https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> Maven staging repository is available at:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1297
>
> This vote will remain open for at least 72 hours.
>
> Yours,
> Your HBase Release Manager
>

Re: [VOTE] Send GitHub notification to issues@hbase

[Yu Li]

+1

Best Regards,
Yu


On Thu, 28 Mar 2019 at 08:50, Zach York 
wrote:

> Will dev@ still get notified when new issues are opened? Or not at all?
>
> +1 if dev@ still gets notified when new issues are opened (how it
> currently
> works with JIRA)
>
> On Wed, Mar 27, 2019 at 5:34 PM Andrew Purtell 
> wrote:
>
> > +1
> >
> >
> > On Wed, Mar 27, 2019 at 12:29 PM Peter Somogyi 
> > wrote:
> >
> > > Hi,
> > >
> > > Right now notification emails from GitHub activities are sent to
> > dev@hbase
> > > for https://github.com/apache/hbase repository. Nick Dimiduk had a
> > > suggestion that these should be forwarded to a different hbase mailing
> > > list.
> > >
> > > Since these kinds of emails are already sent to issues@hbase for the
> > rest
> > > of our repositories (hbase-operator-tools, hbase-connectors and
> > hbase-site)
> > > I recommend doing the same for hbase as well.
> > >
> > > Please vote whether you agree to make the change or you're against it.
> > >
> > > Thanks,
> > > Peter
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>

Re: Are we ready to accept PR commit from github?

[Yu Li]

I'm afraid not for driving this but yes to offer a hand (smile).

Is there already some planned steps ongoing? Infra setup is something I'm
not familiar but required for pre-commit and daily check on Travis, other
than that just count me in and let me know what I could do to help.

Best Regards,
Yu


On Thu, 14 Mar 2019 at 21:26, 张铎(Duo Zhang)  wrote:

> I think PR will be good. Do you have any cycle to drive this Yu Li? Thanks.
>
> Yu Li  于2019年3月14日周四 下午8:53写道：
>
> > I see, thanks for the quick response Peter.
> >
> > Best Regards,
> > Yu
> >
> >
> > On Thu, 14 Mar 2019 at 17:38, Peter Somogyi  wrote:
> >
> > > For hbase repository we do not yet have the integration to accept pull
> > > requests but hbase-connectors and hbase-operator-tools repositories
> moved
> > > to GitHub PR workflow instead of accepting patch files.
> > >
> > > Peter
> > >
> > > On Thu, Mar 14, 2019 at 9:42 AM Yu Li  wrote:
> > >
> > > > Hi All,
> > > >
> > > > Please forgive me if this is already clearly clarified in other mail
> > > > threads, but last time when I saw discussion about this we were still
> > > > lacking some INFRA support to accept PR from github, so I'd like to
> > > double
> > > > check here. Many thanks.
> > > >
> > > > Best Regards,
> > > > Yu
> > > >
> > >
> >
>

Re: Are we ready to accept PR commit from github?

[Yu Li]

I see, thanks for the quick response Peter.

Best Regards,
Yu


On Thu, 14 Mar 2019 at 17:38, Peter Somogyi  wrote:

> For hbase repository we do not yet have the integration to accept pull
> requests but hbase-connectors and hbase-operator-tools repositories moved
> to GitHub PR workflow instead of accepting patch files.
>
> Peter
>
> On Thu, Mar 14, 2019 at 9:42 AM Yu Li  wrote:
>
> > Hi All,
> >
> > Please forgive me if this is already clearly clarified in other mail
> > threads, but last time when I saw discussion about this we were still
> > lacking some INFRA support to accept PR from github, so I'd like to
> double
> > check here. Many thanks.
> >
> > Best Regards,
> > Yu
> >
>

Are we ready to accept PR commit from github?

[Yu Li]

Hi All,

Please forgive me if this is already clearly clarified in other mail
threads, but last time when I saw discussion about this we were still
lacking some INFRA support to accept PR from github, so I'd like to double
check here. Many thanks.

Best Regards,
Yu

Re: [ANNOUNCE] New HBase committer Xu Cang

[Yu Li]

Congratulations and welcome, Xu!

Best Regards,
Yu


On Wed, 6 Feb 2019 at 16:29, Nihal Jain  wrote:

> Congrats :)
>
> On Wed, 6 Feb, 2019, 1:24 PM Balazs Meszaros
> 
> > Congratulations, Xu!
> >
> > On Wed, Feb 6, 2019 at 1:44 AM Sukumar Maddineni
> >  wrote:
> >
> > > Congrats, Xu.
> > >
> > > --
> > > Sukumar
> > >
> > > On Tue, Feb 5, 2019 at 4:41 PM Toshihiro Suzuki 
> > > wrote:
> > >
> > > > Congratulations, Xu!
> > > >
> > > > On Wed, Feb 6, 2019 at 8:34 AM Sakthi 
> > > wrote:
> > > >
> > > > > Congratulations, Xu!
> > > > >
> > > > > Regards,
> > > > > Sakthi
> > > > >
> > > > > On Tue, Feb 5, 2019 at 3:09 PM Geoffrey Jacoby  >
> > > > wrote:
> > > > >
> > > > > > Congratulations, Xu!
> > > > > >
> > > > > > On Tue, Feb 5, 2019 at 2:49 PM Andrew Purtell <
> apurt...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > On behalf of the Apache HBase PMC, I am pleased to announce
> that
> > Xu
> > > > > > > Cang has accepted the PMC's invitation to become a committer on
> > the
> > > > > > > project. We appreciate all of Xu's generous contributions thus
> > far
> > > > and
> > > > > > > look forward to his continued involvement.
> > > > > > >
> > > > > > > Congratulations and welcome, Xu!
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Andrew
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > 
> > >
> >
>

Re: [ANNOUNCE] Please welcome Peter Somogyi to the HBase PMC

[Yu Li]

Congratulations, Peter!

Best Regards,
Yu


On Tue, 22 Jan 2019 at 10:38, Guangxu Cheng  wrote:

> Congratulations Peter!
>
> -
> Best Regards
> Guangxu Cheng
>
> Allan Yang  于2019年1月22日周二 上午10:15写道：
>
> > Congratulations Peter!
> > Best Regards
> > Allan Yang
> >
> >
> > Pankaj kr  于2019年1月22日周二 上午9:49写道：
> >
> > >
> > > Congratulations Peter...!!!
> > >
> > > Regards,
> > > Pankaj
> > >
> > > --
> > > Pankaj Kumar
> > > M: +91-9535197664(India Contact Number)
> > > E: pankaj...@huawei.com
> > > 2012实验室-班加罗尔研究所IT BU分部
> > > 2012 Laboratories-IT BU Branch Dept.HTIPL
> > > From:Duo Zhang 
> > > To:HBase Dev List ;hbase-user <
> > u...@hbase.apache.org
> > > >
> > > Date:2019-01-22 07:06:43
> > > Subject:[ANNOUNCE] Please welcome Peter Somogyi to the HBase PMC
> > >
> > > On behalf of the Apache HBase PMC I am pleased to announce that Peter
> > > Somogyi
> > > has accepted our invitation to become a PMC member on the Apache HBase
> > > project.
> > > We appreciate Peter stepping up to take more responsibility in the
> HBase
> > > project.
> > >
> > > Please join me in welcoming Peter to the HBase PMC!
> > >
> >
>

Re: [NOTICE] project repository URLs have changed

[Yu Li]

How about the 2FA setting? Have you got it configured on github?

Best Regards,
Yu

On Mon, 14 Jan 2019 at 18:03, Reid Chan  wrote:

> >> To make sure, could you find your github username here?:
> https://github.com/orgs/apache/people
>
> Yes, i'm in.
>
>
> >>If so, what's the error message appeared at the MFA status part on:
> https://gitbox.apache.org/setup/?
>
> Msg:
> MFA DISABLED
> Write access suspended. Please make sure you are a part of the ASF
> Organisation on GitHub and have 2FA enabled. Visit id.apache.org and set
> your GitHub ID to be invited to the org. Please allow 15 minutes for your
> MFA status to propagate.
>
>
>
>
>
> --
>
> Best regards,
> R.C
>
>
>
> 
> From: Yu Li 
> Sent: 14 January 2019 17:34
> To: dev
> Cc: Sean Busbey
> Subject: Re: [NOTICE] project repository URLs have changed
>
> To make sure, could you find your github username here?:
> https://github.com/orgs/apache/people
>
> If so, what's the error message appeared at the MFA status part on
> https://gitbox.apache.org/setup/?
>
> On Mon, 14 Jan 2019 at 15:29, Reid Chan  wrote:
>
> > I'm already a member in Apache GitHub organization, and have been waiting
> > for more than 3 days.
> >
> > emm...
> >
> >
> >
> >
> >
> >
> > --
> >
> > Best regards,
> > R.C
> >
> >
> >
> > 
> > From: Yu Li 
> > Sent: 14 January 2019 14:20
> > To: dev
> > Cc: Sean Busbey
> > Subject: Re: [NOTICE] project repository URLs have changed
> >
> > We need to add our github id to our apache profile, as mentioned in below
> > description on https://gitbox.apache.org/setup/
> > *NOTE: You MUST be a part of the Apache GitHub organisation before you
> can
> > complete this setup. If you have not done so already, visit
> id.apache.org
> > <https://id.apache.org/> and add your GitHub ID to your profile. An
> > organisational invite will be sent to you via email shortly thereafter
> > (within 2 hours).*
> >
> > Be patient after you update your profile until receiving the invitation
> > email (may really need 2 hours or so), and after joining the Apache
> Github
> > organization we will need to further wait ~30min before the MFA could be
> > enabled.
> >
> > Good luck and have fun.
> >
> >
> > On Mon, 14 Jan 2019 at 12:35, Reid Chan  wrote:
> >
> > > >> it is possible for committers to enable write access to the GitHub
> > > repository[3]
> > >
> > >
> > > Both Apache account and Github account are authed, but MFA status is
> > > disabled.
> > > Is it normal, or anything i missed?
> > >
> > > Thanks.
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > R.C
> > >
> > >
> > >
> > > 
> > > From: Sean Busbey 
> > > Sent: 10 January 2019 02:30
> > > To: dev
> > > Subject: [NOTICE] project repository URLs have changed
> > >
> > > Hi folks!
> > >
> > > Our project has now transitioned from the old "git-wip" process to the
> > > current ASF infra preferred "gitbox" repository hosting[1].
> > >
> > > The main practical impact for most folks day-to-day is that you will
> > > need to update your git remote url[2]; this is true both for
> > > contributors who want to see up to date changes as well as committers
> > > who wish to push changes.
> > >
> > > tl;dr:
> > >
> > > git remote set-url origin
> https://gitbox.apache.org/repos/asf/hbase.git
> > >
> > > This presumes that you are in the working directory of your git
> > > checkout and that you refer to the main repo as the default remote
> > > name "origin".
> > >
> > > Out of the box, this repository URL should be set to work with the
> > > same credentials, if any, you previously used to interact with the old
> > > git-wip repository. You should be able to both fetch and push as you
> > > have previously done.
> > >
> > > Note that under the gitbox service it is possible for committers to
> > > enable write access to the GitHub repository[3]. By doing so a
> > > committer could work directly with the GitHub PR interface instead of
> > &g

Re: [NOTICE] project repository URLs have changed

[Yu Li]

To make sure, could you find your github username here?:
https://github.com/orgs/apache/people

If so, what's the error message appeared at the MFA status part on
https://gitbox.apache.org/setup/?

On Mon, 14 Jan 2019 at 15:29, Reid Chan  wrote:

> I'm already a member in Apache GitHub organization, and have been waiting
> for more than 3 days.
>
> emm...
>
>
>
>
>
>
> --
>
> Best regards,
> R.C
>
>
>
> 
> From: Yu Li 
> Sent: 14 January 2019 14:20
> To: dev
> Cc: Sean Busbey
> Subject: Re: [NOTICE] project repository URLs have changed
>
> We need to add our github id to our apache profile, as mentioned in below
> description on https://gitbox.apache.org/setup/
> *NOTE: You MUST be a part of the Apache GitHub organisation before you can
> complete this setup. If you have not done so already, visit id.apache.org
> <https://id.apache.org/> and add your GitHub ID to your profile. An
> organisational invite will be sent to you via email shortly thereafter
> (within 2 hours).*
>
> Be patient after you update your profile until receiving the invitation
> email (may really need 2 hours or so), and after joining the Apache Github
> organization we will need to further wait ~30min before the MFA could be
> enabled.
>
> Good luck and have fun.
>
>
> On Mon, 14 Jan 2019 at 12:35, Reid Chan  wrote:
>
> > >> it is possible for committers to enable write access to the GitHub
> > repository[3]
> >
> >
> > Both Apache account and Github account are authed, but MFA status is
> > disabled.
> > Is it normal, or anything i missed?
> >
> > Thanks.
> >
> >
> > --
> >
> > Best regards,
> > R.C
> >
> >
> >
> > 
> > From: Sean Busbey 
> > Sent: 10 January 2019 02:30
> > To: dev
> > Subject: [NOTICE] project repository URLs have changed
> >
> > Hi folks!
> >
> > Our project has now transitioned from the old "git-wip" process to the
> > current ASF infra preferred "gitbox" repository hosting[1].
> >
> > The main practical impact for most folks day-to-day is that you will
> > need to update your git remote url[2]; this is true both for
> > contributors who want to see up to date changes as well as committers
> > who wish to push changes.
> >
> > tl;dr:
> >
> > git remote set-url origin https://gitbox.apache.org/repos/asf/hbase.git
> >
> > This presumes that you are in the working directory of your git
> > checkout and that you refer to the main repo as the default remote
> > name "origin".
> >
> > Out of the box, this repository URL should be set to work with the
> > same credentials, if any, you previously used to interact with the old
> > git-wip repository. You should be able to both fetch and push as you
> > have previously done.
> >
> > Note that under the gitbox service it is possible for committers to
> > enable write access to the GitHub repository[3]. By doing so a
> > committer could work directly with the GitHub PR interface instead of
> > doing so indirectly as we have historically done. We have an ongoing
> > discussion and documentation effort for how we as a community want to
> > handle that work[4]. I'd ask that interested folks participate in said
> > discussion and everyone hold off using our new write access to GitHub
> > until we've documented the consensus position.
> >
> > The changes also impact our "hbase-site" and "hbase-thirdparty"
> > repositories. The gitbox URLs for those repositories are analogous to
> > the one I gave above for the main repo. There is no change to the
> > "hbase-operator-tools" repository, as it has always been on the gitbox
> > service.
> >
> > If you notice an automated process break and it looks related to git,
> > please ping myself and/or Peter Somogyi and we'll help fix any fallout
> > from this transition.
> >
> > -busbey
> >
> > [1]: ASF Infra is decommissioning the "git-wip" project and has
> > required all projects move to the gitbox service. There's more
> > explanation in the thread "[DISCUSS] move to gitbox"
> > https://s.apache.org/lUHS
> >
> > [2]: This isn't true if you already use a remote that points at
> > github. That repository should continue to see updates.
> >
> > [3]: After enabling a sync between your ASF identity and your GitHub
> > identity, the GitHub repo is writable. Committers have "maintainer"
> > access and can both configure the repository settings and push commits
> > directly to GitHub.
> > https://gitbox.apache.org/setup/
> >
> > [4]: HBASE-21701 'Accept pull requests from contributors'
> >
>

Re: [NOTICE] project repository URLs have changed

[Yu Li]

We need to add our github id to our apache profile, as mentioned in below
description on https://gitbox.apache.org/setup/
*NOTE: You MUST be a part of the Apache GitHub organisation before you can
complete this setup. If you have not done so already, visit id.apache.org
 and add your GitHub ID to your profile. An
organisational invite will be sent to you via email shortly thereafter
(within 2 hours).*

Be patient after you update your profile until receiving the invitation
email (may really need 2 hours or so), and after joining the Apache Github
organization we will need to further wait ~30min before the MFA could be
enabled.

Good luck and have fun.


On Mon, 14 Jan 2019 at 12:35, Reid Chan  wrote:

> >> it is possible for committers to enable write access to the GitHub
> repository[3]
>
>
> Both Apache account and Github account are authed, but MFA status is
> disabled.
> Is it normal, or anything i missed?
>
> Thanks.
>
>
> --
>
> Best regards,
> R.C
>
>
>
> 
> From: Sean Busbey 
> Sent: 10 January 2019 02:30
> To: dev
> Subject: [NOTICE] project repository URLs have changed
>
> Hi folks!
>
> Our project has now transitioned from the old "git-wip" process to the
> current ASF infra preferred "gitbox" repository hosting[1].
>
> The main practical impact for most folks day-to-day is that you will
> need to update your git remote url[2]; this is true both for
> contributors who want to see up to date changes as well as committers
> who wish to push changes.
>
> tl;dr:
>
> git remote set-url origin https://gitbox.apache.org/repos/asf/hbase.git
>
> This presumes that you are in the working directory of your git
> checkout and that you refer to the main repo as the default remote
> name "origin".
>
> Out of the box, this repository URL should be set to work with the
> same credentials, if any, you previously used to interact with the old
> git-wip repository. You should be able to both fetch and push as you
> have previously done.
>
> Note that under the gitbox service it is possible for committers to
> enable write access to the GitHub repository[3]. By doing so a
> committer could work directly with the GitHub PR interface instead of
> doing so indirectly as we have historically done. We have an ongoing
> discussion and documentation effort for how we as a community want to
> handle that work[4]. I'd ask that interested folks participate in said
> discussion and everyone hold off using our new write access to GitHub
> until we've documented the consensus position.
>
> The changes also impact our "hbase-site" and "hbase-thirdparty"
> repositories. The gitbox URLs for those repositories are analogous to
> the one I gave above for the main repo. There is no change to the
> "hbase-operator-tools" repository, as it has always been on the gitbox
> service.
>
> If you notice an automated process break and it looks related to git,
> please ping myself and/or Peter Somogyi and we'll help fix any fallout
> from this transition.
>
> -busbey
>
> [1]: ASF Infra is decommissioning the "git-wip" project and has
> required all projects move to the gitbox service. There's more
> explanation in the thread "[DISCUSS] move to gitbox"
> https://s.apache.org/lUHS
>
> [2]: This isn't true if you already use a remote that points at
> github. That repository should continue to see updates.
>
> [3]: After enabling a sync between your ASF identity and your GitHub
> identity, the GitHub repo is writable. Committers have "maintainer"
> access and can both configure the repository settings and push commits
> directly to GitHub.
> https://gitbox.apache.org/setup/
>
> [4]: HBASE-21701 'Accept pull requests from contributors'
>

Re: Nice article on one of our own....

[Yu Li]

Wow! Great job and thank you, Duo!

And I like the "something few people knew about you" part (smile)

Best Regards,
Yu


On Thu, 10 Jan 2019 at 07:11, Sean Busbey  wrote:

> it's a charming profile, Duo!
>
> On Wed, Jan 9, 2019 at 12:42 PM Stack  wrote:
> >
> > See #3 in list of top 5 Apache committers:
> > https://www.cbronline.com/feature/apache-top-5
> > S
>

Re: Rolling 2.1.2 and 2.0.4

[Yu Li]

Memory leak is critical enough to roll a new release, and maybe we should
add a notice somewhere for 2.x users, like our ref guide and/or user
mailing list? Thanks.

Best Regards,
Yu


On Thu, 6 Dec 2018 at 12:39, Reid Chan  wrote:

> +1 for rolling.
>
> Nice found, Zheng Hu. (y)
>
>
> --
>
> Best regards,
> R.C
>
>
>
> 
> From: Stack 
> Sent: 06 December 2018 12:03
> To: HBase Dev List
> Subject: Rolling 2.1.2 and 2.0.4
>
> 2.1.1 and 2.0.3 have an ugly bug found by our Zheng Hu. See HBASE-21551
> Memory leak when use scan with STREAM at server side.
>
> S
>

[ANNOUNCE] Allan Yang joins the Apache HBase PMC

[Yu Li]

On behalf of the Apache HBase PMC I am pleased to announce that Allan Yang
has accepted our invitation to become a PMC member on the Apache HBase
project. We appreciate Allan stepping up to take more responsibility in the
HBase project.

Please join me in welcoming Allan to the HBase PMC!

Best Regards,
Yu

Re: [ANNOUNCE] New HBase committer Jingyun Tian

[Yu Li]

Congratulations and welcome, Jingyun!

Best Regards,
Yu


On Tue, 13 Nov 2018 at 16:46, Srinivas Reddy 
wrote:

> Congratulations Jingyun
>
> -
> Srinivas
>
> - Typed on tiny keys. pls ignore typos.{mobile app}
>
> On Tue 13 Nov, 2018, 15:54 张铎(Duo Zhang) 
> > On behalf of the Apache HBase PMC, I am pleased to announce that Jingyun
> > Tian has accepted the PMC's invitation to become a committer on the
> > project. We appreciate all of Jingyun's generous contributions thus far
> and
> > look forward to his continued involvement.
> >
> > Congratulations and welcome, Jingyun!
> >
>

Re: [ANNOUNCE] Please welcome Zach York to the HBase PMC

[Yu Li]

Congratulations and welcome, Zach!

Best Regards,
Yu


On Wed, 17 Oct 2018 at 13:02, Pankaj kr  wrote:

> Congratulations Zach..!! :)
>
> Regards,
> Pankaj
>
> -Original Message-
> From: Sean Busbey [mailto:bus...@apache.org]
> Sent: 12 October 2018 01:32
> To: dev 
> Subject: [ANNOUNCE] Please welcome Zach York to the HBase PMC
>
> On behalf of the Apache HBase PMC I am pleased to announce that Zach York
> has accepted our invitation to become a PMC member on the Apache HBase
> project. We appreciate Zach stepping up to take more responsibility in the
> HBase project.
>
> Please join me in welcoming Zach to the HBase PMC!
>
> As a reminder, if anyone would like to nominate another person as a
> committer or PMC member, even if you are not currently a committer or PMC
> member, you can always drop a note to priv...@hbase.apache.org to let us
> know.
>

Re: About China meetups and how-to-contribute

[Yu Li]

Thanks for the quick response boss!

bq. What could we do to move the conversation up on to hbase.apache.org?
Special mailing list?
Oh I just meant to add a link of the meetup summary page onto
hbase.apache.org, like hbasecon :-)
I like the idea about allowing Chinese in @dev  list,
but a special mailing list for Chinese discussion is also a good option,
hard to tell which is better (smile)

bq. No need to wait...
I see, will do. And thanks for the reference about documentation
contributing, really something I neglected.

bq. You can use it as long as you include trademark and along the bottom of
the page its says
Could you tell more about how to "include trademark" boss? From the
hbasecon page I could see below lines but do we need to ask for permission
from ASF? Thanks.

"*Apache Hadoop, Apache HBase, Hadoop, HBase, and Apache are trademarks of
the Apache Software Foundation and are used with permission. All other
trademarks and registered trademarks are the property of their respective
owners.*"

Best Regards,
Yu


On Wed, 5 Sep 2018 at 11:34, Stack  wrote:

> On Tue, Sep 4, 2018 at 8:11 PM Yu Li  wrote:
>
>> Hi boss,
>>
>> As mentioned in our HBaseConAsia, multiple meet ups are ongoing here in
>> China, and we have a website[1] for propagation and recording but all in
>> Chinese. Do you think it's ok to add a link in the "News" section on our
>> hbase.apache.org? Do we need any discuss/vote thread about this?
>>
>
> No need. Could announce on the user and dev mailing lists too Perhaps
> a preamble in english and then in chinese.
>
> Sean and I have been talking about how the dev list does not need to be in
> english. There are no rules. We were thinking of bringing it up.
>
> Would be great if discussion was on the dev@hbase list, whatever the
> language.
>
> If we want to follow-along, google translate works well-enough.
>
> What could we do to move the conversation up on to hbase.apache.org?
> Special mailing list?
>
>
>
>>
>> I'm also asked to write a Chinese article about how to contribute code to
>> HBase and become a committer. I think there're multiple references[2][3][4]
>> but please let me know if any special note. And I guess I should also wait
>> for our discussion result about github PR process?
>>
>>
> No need to wait. Can just use it as illustration of how stuff is done in
> the community, that we have been using one process for a long time but now
> community is trying to figure how to incorporate github...not only hbase
> but apache too via tooling and process.
>
>
>> btw, I noticed about the HBase logo on the web page and have asked them
>> to change. It's a trade mark and we could not use it w/o authorization,
>> right?
>>
>>
> You can use it as long as you include trademark and along the bottom of
> the page its says... something like what is on the hbasecon page:
> http://hbase.apache.org/www.hbasecon.com/
>
> You saw
> http://hbase.apache.org/book.html#appendix_contributing_to_documentation ?
>
>
>> Sorry for so many questions boss, and have a good day.
>>
>>
> Any time!
>
>
> S
>
>
>> [1] http://hbase.group/?/topic/HBase%20Meetup
>> [2] http://hbase.apache.org/book.html#developing
>> [3] https://issues.apache.org/jira/browse/HBASE-18974
>> [4] https://s.apache.org/BlT0
>>
>> Best Regards,
>> Yu
>>
>

Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning")

[Yu Li]

Just checked Flink document more carefully, it requires to file a JIRA but
no mention of creating account or assigning to oneself. However, I think
it's OK to require our contributor to create a JIRA account with the same
email address as github account - it requires no big effort and gives
people credit (telling who resolves the issue) - or at least we could make
it a strong recommendation.

Maybe I'm too old to guess the young generation's thought, but I believe
process won't be the obstacle of contributing if one really loves open
source, not to mention it's a one-time effort (smile)

Best Regards,
Yu


On Tue, 4 Sep 2018 at 10:43, Josh Elser  wrote:

>
>
> On 9/2/18 12:00 PM, Sean Busbey wrote:
> > On Mon, Aug 20, 2018, 22:09 Stack  wrote:
> >
> >> This came up at the recent devs meeting: could we move to github flow
> >> committing to Apache HBase? Do folks want this? If so, what would it
> take?
> >> What would it look like?
> >>
> >> The new gitbox repos at apache allow contribution back into apache via
> >> github tooling: PRs can be merged into apache repos with a click of a
> >> button, github-based comments can show as comments in apache JIRA. The
> new
> >> hbase-operator-tools and hbase-connector repos are gitbox based. We can
> run
> >> experiments there with fear of damage to the core.
> >>
> >> The justification is that if our project supported PRs and contribution
> via
> >> github, we could glean more contributors.
> >>
> >> Below I repeat two follow-on comments taken from the "Rough notes from
> dev
> >> meetup, day after hbaseconasia 2018, saturday morning" thread by way of
> a
> >> kickstart:
> >>
> >>  From our Josh Elser:
> >>
> >>> This [supporting PRs] is something the PMC should take to heart. If we
> >> are excluding
> >>> contributions because of how we choose accept them, we're limiting our
> >> own
> >>> growth. Do we have technical reasons (e.g. PreCommit) which we cannot
> >> accept
> >>> PR's or is it just because "we do patches because we do patches"?
> >>>
> >>
> >> By our Sean:
> >>
> >> "I don't want to bog down this thread, but there are a ton of
> >> unanswered questions for allowing github PRs.
> >>
> >> "The biggest one for me is that JIRA is currently our best hope for an
> >> authoritative place for authorship information. If we're taking PRs
> >> from folks who have GitHub accounts but find ASF JIRA accounts too
> >> burdensome, what are we putting for the author in JIRA? Am I going to
> >> have to look in JIRA before a certain date and in Git after? Or in Git
> >> only if JIRA is set to some "HBase Contributor from GitHub" account?"
> >>
> >> Thanks,
> >> St.Ack
> >>
> >
> >
> > Hey folks,
> >
> > This authorship bit might be coming up now. There's a PR for an existing
> > JIRA issue that I'd like to accept, but AFAICT the PR author doesn't
> have a
> > JIRA account.
> >
> > I've asked them about it. If they don't have an account and don't want to
> > make one, I suppose I'll make a placeholder JIRA account and send the
> > details to the PMC, unless someone objects.
> >
> > I'm not happy about the bifrucation of authorship information but I don't
> > see how forcing JIRA account creation could possibly be sustainable.
>
> Maybe I'm missing something, but what does an "empty" Jira account just
> to assign a Jira issue to actually get us over "Unassigned"? To Andrew's
> point about the committer ensuring IP provenance for changes hitting the
> repo to satisfy ASF requirements, I think that's orthogonal to having a
> Jira name tied to it, right?
>
> Maybe I'm missing something though?
>

Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning")

[Yu Li]

Maybe we could follow some other projects' process? For example I could
find below lines of Flink's Code of Conduct
, JFYI:

*Before you start coding…*

*…please make sure there is a Jira issue that corresponds to your
contribution. This is a general rule that the Flink community follows for
all code contributions, including bug fixes, improvements, or new features,
with an exception for trivial hot fixes. If you would like to fix a bug
that you found or if you would like to add a new feature or improvement to
Flink, please follow the File a bug report
 or Propose
an improvement or a new feature

guidelines
to open an issue in Flink’s Jira
 before starting with the
implementation.*

Best Regards,
Yu


On Mon, 3 Sep 2018 at 00:52, Andrew Purtell 
wrote:

> It's on us as committers to ensure Apache policies on code contribution
> are followed. I think that is the bottom line. Our identities are known to
> Apache infrastructure and recorded in commit history. By committing we are
> asserting we believe the provenance of the contribution is known and
> conforms to Apache policy. If you have concerns then don't commit.
> Otherwise, it is the same as it always was. Both of Apache's JIRA instance
> and Github offer self service account signups without any sort of identity
> verification, only verification that the email account provided is valid
> and under the control of the contributor.
>
> I think opening placeholder JIRAs as committers because we need it for
> tracking is fine. With my PMC hat on I'd like to wonder aloud what is the
> problem with signing up to Apache's JIRA instance. Any reason to be
> concerned? I take it you don't think so. I also take it you believe you
> know the identity of the contributor. Assuming you answer in the
> affirmative I don't see that we have any issues.
>
>
> > On Sep 2, 2018, at 9:00 AM, Sean Busbey  wrote:
> >
> >> On Mon, Aug 20, 2018, 22:09 Stack  wrote:
> >>
> >> This came up at the recent devs meeting: could we move to github flow
> >> committing to Apache HBase? Do folks want this? If so, what would it
> take?
> >> What would it look like?
> >>
> >> The new gitbox repos at apache allow contribution back into apache via
> >> github tooling: PRs can be merged into apache repos with a click of a
> >> button, github-based comments can show as comments in apache JIRA. The
> new
> >> hbase-operator-tools and hbase-connector repos are gitbox based. We can
> run
> >> experiments there with fear of damage to the core.
> >>
> >> The justification is that if our project supported PRs and contribution
> via
> >> github, we could glean more contributors.
> >>
> >> Below I repeat two follow-on comments taken from the "Rough notes from
> dev
> >> meetup, day after hbaseconasia 2018, saturday morning" thread by way of
> a
> >> kickstart:
> >>
> >> From our Josh Elser:
> >>
> >>> This [supporting PRs] is something the PMC should take to heart. If we
> >> are excluding
> >>> contributions because of how we choose accept them, we're limiting our
> >> own
> >>> growth. Do we have technical reasons (e.g. PreCommit) which we cannot
> >> accept
> >>> PR's or is it just because "we do patches because we do patches"?
> >>>
> >>
> >> By our Sean:
> >>
> >> "I don't want to bog down this thread, but there are a ton of
> >> unanswered questions for allowing github PRs.
> >>
> >> "The biggest one for me is that JIRA is currently our best hope for an
> >> authoritative place for authorship information. If we're taking PRs
> >> from folks who have GitHub accounts but find ASF JIRA accounts too
> >> burdensome, what are we putting for the author in JIRA? Am I going to
> >> have to look in JIRA before a certain date and in Git after? Or in Git
> >> only if JIRA is set to some "HBase Contributor from GitHub" account?"
> >>
> >> Thanks,
> >> St.Ack
> >>
> >
> >
> > Hey folks,
> >
> > This authorship bit might be coming up now. There's a PR for an existing
> > JIRA issue that I'd like to accept, but AFAICT the PR author doesn't
> have a
> > JIRA account.
> >
> > I've asked them about it. If they don't have an account and don't want to
> > make one, I suppose I'll make a placeholder JIRA account and send the
> > details to the PMC, unless someone objects.
> >
> > I'm not happy about the bifrucation of authorship information but I don't
> > see how forcing JIRA account creation could possibly be sustainable.
> >
> >>
>

Re: [VOTE] The first HBase 1.4.7 release candidate (RC0) is available

[Yu Li]

+1 (binding)

Checked sums and signatures: ok
Built from source: ok (7u79)
RAT check: ok (7u79)
Unit tests pass: ok (7u79)
Server web UI: ok, checked master/RS UI, table details page, debug dump,
metrics dump, everything looks good
Shell commands: ok (8u101), ran DDL/DML/flush/compact/split/merge_region
commands, everything looks good
Loaded 1M rows with LTT: ok (8u101), all keys verified, latency and logs
looks good

Best Regards,
Yu


On Sun, 2 Sep 2018 at 08:25, Andrew Purtell  wrote:

> You need to refetch my key. I recently extended its lifetime.
>
> On Sat, Sep 1, 2018 at 5:15 PM Stack  wrote:
>
> > I tried to verify signature but says expired. You see that Andy?
> >
> > kalashnikov:1.4.7 stack$ gpg verify hbase-1.4.7-src.tar.gz.asc
> > usage: gpg [options] [filename]
> > kalashnikov:1.4.7 stack$ gpg --verify hbase-1.4.7-src.tar.gz.asc
> > gpg: assuming signed data in 'hbase-1.4.7-src.tar.gz'
> > gpg: Signature made Tue Aug 28 14:58:26 2018 PDT using RSA key ID
> D5365CCD
> > gpg: Good signature from "Andrew Purtell (CODE SIGNING KEY) <
> > apurt...@apache.org>" [expired]
> > gpg: Note: This key has expired!
> > Primary key fingerprint: 50F1 E8BB 7C67 AB14 BDFC  0A21 8597 754D D536
> 5CCD
> >
> > S
> >
> >
> > On Tue, Aug 28, 2018 at 3:11 PM Andrew Purtell 
> > wrote:
> >
> > > The first HBase 1.4.7 release candidate (RC0) is available for download
> > at
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.7RC0/ and Maven
> > > artifacts are available in the temporary repository
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1230/
> > .
> > >
> > > The git tag corresponding to the candidate is '1.4.7RC0' (763f27f583).
> > >
> > > A detailed source and binary compatibility report for this release is
> > > available for your review at
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.7RC0/compat-check-report.html
> > > . There are no reported compatibility issues.
> > >
> > > A list of the 18 issues resolved in this release can be found at
> > > https://s.apache.org/PvLv .
> > >
> > > Please try out the candidate and vote +1/0/-1.
> > >
> > > The vote will be open for at least 72 hours. Unless objection I will
> try
> > to
> > > close it Monday September 3, 2018 if we have sufficient votes.
> > >
> > > Prior to making this announcement I made the following preflight
> checks:
> > >
> > > RAT check passes (7u80)
> > > Unit test suite passes (7u80)
> > > LTT load 1M rows with 100% verification and 20% updates (8u181)
> > > ITBLL 500M rows with slowDeterministic and serverKilling monkies
> > > (8u181)
> > >
> > > --
> > > Andrew
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: PMC: Need one more binding vote on 1.4.7 RC0

[Yu Li]

Let me do the job, will come back with voting before deadline.

Best Regards,
Yu


On Sat, 1 Sep 2018 at 07:34, Andrew Purtell  wrote:

> So far we have two binding +1s and three nonbinding +1s.
> I'd like to close the vote this coming Monday. Thanks!
>
>
> --
> Best regards,
> Andrew
>

Re: Pictures, Videos and Slides for HBaseConAsia2018

[Yu Li]

Thank you for all the helps Stack! It must have cost lots of your time
downloading the videos then uploading to youtube, uploading slides onto
slideshare, and put up all together into the blog!

The success of the conference is attributed to all PC members and supports
from hbase community rather than me alone (smile)

Best Regards,
Yu


On Sat, 1 Sep 2018 at 03:12, Stack  wrote:

> On Fri, Aug 31, 2018 at 10:22 AM Chetan Khatri <
> chetan.opensou...@gmail.com>
> wrote:
>
> > Thank you Stack for everything.
> >
> >
> Thanks Chetan but our mighty Yu Li did all the work!
> S
>
>
>
> > On Fri, Aug 31, 2018 at 8:18 PM Stack  wrote:
> >
> > > I blew the cobwebs off our blog and put up a short note on the
> conference
> > > by Yu Li and myself. See here: https://blogs.apache.org/hbase/
> > >
> > > S
> > >
> > > On Wed, Aug 22, 2018 at 3:03 AM Yu Li  wrote:
> > >
> > > > Hi all,
> > > >
> > > > HBaseConAsia2018 is successfully held on Aug. 17th in Beijing, China
> > and
> > > > please following below links for a quick review:
> > > >
> > > > Pictures:
> > > >
> > https://drive.google.com/drive/folders/1eGuNI029a78s_BdH37VsSr4uOalyLi5O
> > > >
> > > > Slides and Video recording:
> > > > https://yq.aliyun.com/articles/626119
> > > >
> > > > Enjoy it and let's expect the next year!
> > > >
> > > > Yu - on behalf of HBaseConAsia2018 PC
> > > >
> > >
> >
>

Pictures, Videos and Slides for HBaseConAsia2018

[Yu Li]

Hi all,

HBaseConAsia2018 is successfully held on Aug. 17th in Beijing, China and
please following below links for a quick review:

Pictures:
https://drive.google.com/drive/folders/1eGuNI029a78s_BdH37VsSr4uOalyLi5O

Slides and Video recording:
https://yq.aliyun.com/articles/626119

Enjoy it and let's expect the next year!

Yu - on behalf of HBaseConAsia2018 PC

HBaseConAsia2018 successfully held

[Yu Li]

Dear all,

As chairman of the conference, I'm glad to announce the success of
HBaseConAsia2018 (Aug. 17th, Beijing, China). There were totally 494
attendees at scene and 14796 views from live broadcast. Shared are part of
the pictures and more coming, slides and videos will be uploaded later
(will use another thread for notification when it's ready).
 HBaseConAsia2018_Pictures

Please also allow me to express my great thanks to all PC members (both
community PC and Alibaba local PC). We wouldn't have made it without your
help!

Just let us know if you have any suggestions about the conference, and
let's expect the next year!

Best Regards,
Yu

Re: Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning

[Yu Li]

Good one boss, please teach me how to do shorthand next time ^o^

Some supplement/comments below.

bq. Lucent (lucene?) has a perf curve on home page with markings for when
large features arrived and when releases were cut so can see if
increase/decrease in perf.
Yes Lucene. Should be this page about benchmark
 and curves like this
, I believe
this will help a lot for users to decide which version to use and what to
notice.

bq. One attendee suggested the async core be done with coroutine. Was
asked, which JDK has coroutine. Answer, the AJDK. Whats that? The Alibaba
JDK (they have their own JDK team)
Kotlin was also mentioned and more details on this link
. There're
also some other existing coroutine implementations in java, please check this
link

on stackoverflow.
Still plan to upstream what we have based on SEDA and queues/callbacks and
in parallel people with interests could check coroutine tech (smile)

bq. One attendee asked where does hbase want to go? Is it storage or a db
system? Need to draw a sharp line. Do what we are good at.
Wish more people could respond to this question, maybe throwing a separate
thread even to the @user list? Shall we have some discussion in our PMC
list?
*HBase is a mature project but are we too old to innovate and evolve? Where
is our passion and ambition? I want to see the answer. We need to see the
answer.*

Maybe we should extract some umbrella JIRAs to further discuss/move on?
Turning the discussion into plans and action.

Thanks.


Best Regards,
Yu

On 19 August 2018 at 18:57, Stack  wrote:

> Attendees! If anything to add, pile it on of if error, please correct.
> S
>
> On Sun, Aug 19, 2018 at 6:48 PM Stack  wrote:
>
> > There were about 30 of us. I didn't take roll. See photos below [1][2].
> > PMCers, committers, contributors, and speakers from the day before. There
> > is no attribution of comments or ideas. Please excuse. No agenda.
> >
> > TESTING
> > What do people do testing?
> > Allan Yang is finding good stuff when he tests AMv2 compared to me. Why?
> > slowDeterministic does more op types than serverKilling.
> > What do others do for testing?
> > Add more variety to the ITBLLs, more chaos?
> > What for performance testing?
> > YCSB.
> > Batch is important. Its what our users do. Recent addition of batch in
> > YCSB (and in PerformanceEvaluation). Size of batch matters too. And
> number
> > of clients.
> > Alibaba described what they do.
> > Advocate that we all try different test types rather than all do same
> runs.
> > Need to add new async client into YCSB. Alibaba use it for their testing
> > of new SEDA core (upstreaming soon).
> > Understanding each others benchmarks can take a while. Common
> > understanding takes some effort, communication.
> > New hbase-operation-tools will be good place to put perf and testing
> > tooling.
> >
> > GITHUB
> > Can hbase adopt the github dev flow? Support PRs?
> > Its a case of just starting the discussion on the dev list?
> > Do we lose review/commentary information if we go github route? Brief
> > overview of what is possible w/ the new gitbox repos follows ultimately
> > answering that no, there should be no loss (github comments show as jira
> > comments).
> > Most have github but not apache accounts. PRs are easier. Could encourage
> > more contribution, lower the barrier to contrib.
> > Other tools for hbase-operation-tools would be stuff like the alibaba
> > tooling for shutting down servers... moving regions to new one.
> >
> > PERF ACROSS VERSIONS
> > Lucent (lucene?) has a perf curve on home page with markings for when
> > large features arrived and when releases were cut so can see if
> > increase/decrease in perf.
> > There was a big slowdown going from 0.98 to 1.1.2 hbase.
> > We talked about doing such a perf curve on hbase home page. Would be a
> big
> > project. Asked if anyone interested?
> > Perhaps a dedicated cluster up on Apache. We could do a whip-around to
> pay
> > for it.
> >
> > USER FRIENDLY
> > Small/new users have a hard time. Is there a UI for users to see data in
> > cells or to change schema, or to create/drop tables. Is there anything we
> > can do here?
> > Much back and forth.
> > Xiaomi don't let users have access to shell. Have a web ui where you
> click
> > to build command that is run for you. Afraid that users will mistakenly
> > destroy the database so shudown access.
> > It turns out that most of the bigger players present have some form of UI
> > built against hbase. Alibaba have something. The DiDi folks have howto
> wiki
> > pages.
> > Talked about upstreaming.
> > Where to put it? hbase-operator-tools?
> > What about Docker file to give devs their own hbase easily. Can throw
> away
> > when done.
> > One attendee 

Live Broadcast link for HBaseConAsia2018

[Yu Li]

Hi All,

HBaseConAsia2018 is ongoing and here comes the live broadcast link[1].
Please follow the link to watch the speaks if failed to come to the scene.
Enjoy the day.

大家好，

HBaseConAsia2018正在北京歌华开元大酒店进行中，对于无法到现场的用户我们提供了直播链接[1]，大家可以在网上观看直播。

[1]
https://yq.aliyun.com/promotion/631?id=129203=groupmessage=0

Yu - On behalf of the HBaseConAsia2018 PC

HBaseConAsia2018 registration closed

[Yu Li]

Hi All,

HBaseConAsia2018[1] will be held on this Friday (Aug. 17th) in Beijing,
China and now the registration is closed.
HBaseConAsia2018将于本周五在北京举行，大会门票注册即刻起关闭。

We will send the check-in code to all successful orders through email and
sms, please remember it (you may not be allowed to enter the conference
hall w/o checkin code).
我们将通过邮件和短信的方式将验证码发送给注册成功的人员，请牢记该验证码。如果没有验证码您将有可能被禁止进入会场。

All registrations from eventbrite will also receive the checkin code and
please note that this code suppresses the eventbrite one.
通过eventbrite渠道成功注册的人员也将收到该验证码，请注意这是我们唯一使用的验证码，凭eventbrite的order信息将无法进入会场。

Look forward to meeting you at the conference!
期待在会议当天和您见面！

- Yu (on behalf of the HBaseConAsia2018 PC)

[1] https://hbase.apache.org/hbaseconasia-2018

HBaseConAsia 2018 Coming!

[Yu Li]

Hi All,

HBaseConAsia2018[1] will be held on Aug. 17th in Beijing, China, and we're
almost there. We have speakers from experts all over the world, including 7
HBase PMC members. Please check more details about speakers and agenda on
our website[2] (speaker name and agenda in English although a Chinese
website, so please just scroll down the page and don't worry)

HBaseConAsia2018[1]将于8月17日在中国北京召开，并且已经准备就绪。我们邀请到了全世界非常优秀的HBase专家作为演讲嘉宾和大家分享HBase在Pintrest/Intel/阿里巴巴/小米/华为/滴滴等一线公司的使用经验，其中包括7位HBase
PMC成员。请访问官方主页[2]了解详细的演讲嘉宾阵容和会议日程

This year we don't only have track on HBase internal (dev), but also on
HBase ecology/solution/applications. The conference is FREE for tickets and
the registration is still open, please schedule your time and register on
our websites [3] [4]. Look forward to meeting you at the conference!

今年大会的主题不仅限于HBase内部（开发／运维）议题，还包括HBase生态／解决方案／应用。会议门票免费，并且目前注册仍未关闭。欢迎大家及时注册，并期待在会议当天和大家见面！

- Yu (on behalf of the HBase PMC)

[1] https://hbase.apache.org/hbaseconasia-2018
[2] https://m.aliyun.com/markets/aliyun/hbaseconasia2018
[3] https://hbaseconasia2018-tickets.eventbrite.com
[4] https://page.aliyun.com/form/hbasecon/page.htm

Re: [ANNOUNCE] New Committer: Toshihiro Suzuki

[Yu Li]

Congratulations and welcome, Toshihiro!

Best Regards,
Yu

On 2 August 2018 at 09:35, Pankaj kr  wrote:

> Congratulations Toshihiro..!!
>
>
> Thanks & Regards,
> Pankaj Kumar
> Technical Project Leader
> Enterprise Intelligence, IT BU
>
> Huawei Technologies India Pvt. Ltd.
> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
> Bengaluru-560066, Karnataka
> Tel: + 91-80-49160700 Ext. 71678, Mob: 9535197664,  Email:
> pankaj...@huawei.com
>
> 
> __
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
> -Original Message-
> From: Josh Elser [mailto:els...@apache.org]
> Sent: Wednesday, August 01, 2018 8:17 PM
> To: dev 
> Subject: [ANNOUNCE] New Committer: Toshihiro Suzuki
>
> On behalf of the HBase PMC, I'm pleased to announce that Toshihiro Suzuki
> (aka Toshi, brfn169) has accepted our invitation to become an HBase
> committer. This was extended to Toshi as a result of his consistent,
> high-quality contributions to HBase. Thanks for all of your hard work, and
> we look forward to working with you even more!
>
> Please join me in extending a hearty "congrats" to Toshi!
>
> - Josh
>

Re: [VOTE] The first HBase 1.4.6 release candidate (RC0) is available

[Yu Li]

The same observation on TestExportSnapshot as noted.

Best Regards,
Yu

On 31 July 2018 at 03:14, Andrew Purtell  wrote:

> > TestExportSnapshot and TestRegionServerHostname failed/timed-out,
> respectively
>
> Thanks, they didn't fail for me but let me add these to the list of flakes
> to follow up on.
>
>
> On Mon, Jul 30, 2018 at 12:12 PM Josh Elser  wrote:
>
> > +1 (binding)
> >
> > * xsums/sigs good
> > * UTs mostly good (TestExportSnapshot and TestRegionServerHostname
> > failed/timed-out, respectively)
> > * Src release is just source only
> >
> > Sorry for the delay -- got held up re-running UTs after my /etc/hosts
> > was busted :)
> >
> > On 7/25/18 2:35 PM, Andrew Purtell wrote:
> > > The first HBase 1.4.6 release candidate (RC0) is available for download
> > at
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.6RC0/ and Maven
> > > artifacts are available in the temporary repository
> > > https://repository.apache.org/content/repositories/
> orgapachehbase-1226/
> > .
> > >
> > > The git tag corresponding to the candidate is '1.4.6RC0' (a55bcbd4fc).
> > >
> > > A detailed source and binary compatibility report for this release is
> > > available for your review at
> > >
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.6RC0/
> compat-check-report.html
> > > . There is an added method to the LimitedPrivate interface
> > ReplicationPeer
> > > which will not cause binary compatibility issues but will require
> source
> > > changes at recompilation. This type of additive change is allowed. The
> > > internal utility class Base64 has been made private and so the related
> > > changes are allowed.
> > >
> > > A list of the 34 issues resolved in this release can be found at
> > > https://s.apache.org/kolm .
> > >
> > > Please try out the candidate and vote +1/0/-1.
> > >
> > > This vote will be open for at least 72 hours. Unless objection I will
> try
> > > to close it Monday July 30, 2018 if we have sufficient votes.
> > >
> > > Prior to making this announcement I made the following preflight
> checks:
> > >
> > >  RAT check passes (7u80)
> > >  Unit test suite passes (7u80)
> > >  LTT load 1M rows with 100% verification and 20% updates (8u172)
> > >  ITBLL Loop 1 500M rows with serverKilling monkey (8u172)
> > >
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] The first HBase 1.4.6 release candidate (RC0) is available

[Yu Li]

+1 (binding)

Checked sums and signatures: ok
Built from source: ok (7u79)
RAT check: ok (7u79)
Unit tests pass: ok (7u79)
- Note: TestExportSnapshot and TestSecureExportSnapshot keeps failing in my
local env
- I'd suggest to backport HBASE-16634/16671/17970 (rough check, no enough
time to dig into it), but IMHO this is NOT a blocking issue.
Shell commands: ok (8u101), ran DDL/flush/compact/split commands,
everything looks good
Loaded 1M rows with LTT: ok (8u101), all keys verified, latency and logs
looks good

Best Regards,
Yu

On 30 July 2018 at 18:19, Balazs Meszaros <
balazs.mesza...@cloudera.com.invalid> wrote:

> +1
>
> - signatures, shasum: OK
> - rat check: OK
> - built from source (8u122): OK
> - unit tests: OK
> - web UI: OK
> - basic shell operations: OK
> - LTT with 1M rows: OK
>
> Best regards,
> Balazs
>
> On Mon, Jul 30, 2018 at 10:46 AM Peter Somogyi 
> wrote:
>
> > +1 (non-binding)
> >
> > Signatures, checksums correct
> > RAT check passed (8u171)
> > Unit tests passed (8u171)
> > LTT 1M rows passed
> > Web UI looks correct
> > Simple shell commands work
> >
> > Thanks for the release,
> > Peter
> >
> > On Wed, Jul 25, 2018 at 8:36 PM Andrew Purtell 
> > wrote:
> >
> > > The first HBase 1.4.6 release candidate (RC0) is available for download
> > at
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.6RC0/ and Maven
> > > artifacts are available in the temporary repository
> > > https://repository.apache.org/content/repositories/
> orgapachehbase-1226/
> > .
> > >
> > > The git tag corresponding to the candidate is '1.4.6RC0' (a55bcbd4fc).
> > >
> > > A detailed source and binary compatibility report for this release is
> > > available for your review at
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.6RC0/
> compat-check-report.html
> > > . There is an added method to the LimitedPrivate interface
> > ReplicationPeer
> > > which will not cause binary compatibility issues but will require
> source
> > > changes at recompilation. This type of additive change is allowed. The
> > > internal utility class Base64 has been made private and so the related
> > > changes are allowed.
> > >
> > > A list of the 34 issues resolved in this release can be found at
> > > https://s.apache.org/kolm .
> > >
> > > Please try out the candidate and vote +1/0/-1.
> > >
> > > This vote will be open for at least 72 hours. Unless objection I will
> try
> > > to close it Monday July 30, 2018 if we have sufficient votes.
> > >
> > > Prior to making this announcement I made the following preflight
> checks:
> > >
> > > RAT check passes (7u80)
> > > Unit test suite passes (7u80)
> > > LTT load 1M rows with 100% verification and 20% updates (8u172)
> > > ITBLL Loop 1 500M rows with serverKilling monkey (8u172)
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
>