[VOTE] First release candidate for HBase 1.2.6.1 (RC0) is available
Hi! The first release candidate for Apache HBase 1.2.6.1 is available for download and testing. Artifacts are available here: https://dist.apache.org/repos/dist/dev/hbase/1.2.6.1RC0/ You can find the SHA512 of the artifacts as of this email at the end. Corresponding convenience artifacts for maven use are in the staging repository: https://repository.apache.org/content/repositories/orgapachehbase-1218/ All artifacts are signed with my code signing key, 0D80DB7C, which is also in the project KEYS file: http://www.apache.org/dist/hbase/KEYS These artifacts correspond to commit ref 61297b5e3acf2a77606b59e0b6f0013c9dae0fbb which has been tagged as 1.2.6.1RC0 as a convenience. Please take a few minutes to verify the release and vote on releasing it: [ ] +1 Release these artifacts as Apache HBase 1.2.6.1 [ ] -1 Do not release this package because ... This VOTE thread will remain open for at least 72 hours. -busbey as of this email the posted artifacts have the following SHA512. hbase-1.2.6.1-src.tar.gz: 02A44970 2614D148 7B2162A5 9AC23837 FC2583BC 068BC8D8 8FCB1C30 3FE38D2D 403727D5 E7103FF7 7FDF65B1 1F4DFF3D 7E9945BE A5A9453F 4FE0AE0A A56C28FE hbase-1.2.6.1-bin.tar.gz: EB473744 184430BE 55E8DAF2 A6450E2F 06281960 13D473D0 596779AB 2F1EEFBA 1BB76273 F1C48BCD FCAB1A33 2AFCB649 B0BC3EF8 B2756540 70E7E375 F5CFC43A
Re: [VOTE] Apache HBase 1.3.2.1RC0
are there maven artifacts that go with? On Sat, Jun 2, 2018 at 4:26 PM, Josh Elser wrote: > Hi, > > Please vote to approve the following as Apache HBase 1.3.2.1 > > https://dist.apache.org/repos/dist/dev/hbase/1.3.2.1RC0/ > > Per usual, there is a source release as well as a convenience binary > > This is built with JDK7 from the commit: > https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=commit;h=bf25c1cb7221178388baaa58f0b16a408e151a69 > (there is a corresponding tag "1.3.2.1RC0" for convenience) > > hbase-1.3.2.1-bin.tar.gz: 1D CB 27 E0 B0 56 28 B8 BE C7 41 03 2E B5 D3 31 > hbase-1.3.2.1-src.tar.gz: 47 99 46 3C 2B E2 59 9B 5B 8B 2F 16 81 53 6B FE > hbase-1.3.2.1-bin.tar.gz: 16EB62DA D4EA40F6 DD8747CF 6A49678E D1A4A53E > B3A9E67D > C53A89F1 471D1DC5 5147E5CA D1AED8B0 B22A01F5 > C1F6F6CA > 4B4E9562 61CDA9B6 91D94C16 26593AFB > hbase-1.3.2.1-src.tar.gz: 63C55C02 DB27461E 2C006758 329EC21E E14823E3 > 9080105B > 43FA6EF2 05BD81A3 D526E2AC 6EAE0FE9 1C3103F4 > 20B8457F > 3C94EF73 5B3CB18C 85B7E0AB 4311CAA4 > > This vote will be open for at least 72 hours (2018/06/05 2130 UTC). > > - Josh (on behalf of the HBase PMC)
Re: On the 2.1.0 and 3.0.0 release
I think it is expected that we have more patch releases for minor releases like 2.0.x and 1.1.x. As a new major release is expected to be unstable in the beginning. Even if we want to retire 2.0.x ASAP, I still think we need a have a 2.0.1 release... Stack 于2018年6月4日 周一12:16写道： > On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang) > wrote: > > > What;s your plan sir? Branch branch-2.1 from branch-2.0? > > > > > Its a suggestion. > > I like Andrew's notion that we left-shift how we have been thinking about > version numbers; that we releases tend toward minor increments rather than > patch increments as we have been doing up to this. > > If we are going to act on Andrew's suggestion, now is the time to do it. > > 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but > with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in > production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug > and perf improvements only. > > We already have enough to define a substantial 3.0.0 IMO what with serial > replication and HBASE-20312 CCSMap. > > I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to > ship. Meantime we accumulate a mountain of testing, perf, and whatever else > tech debt. > > What do folks think? > > Thanks, > S > > > > > > 2018-06-04 11:50 GMT+08:00 Stack : > > > > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) > > > wrote: > > > > > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished > > > features > > > > will be disabled by default or purged from branch-2.1 and target to > 2.2 > > > > release. > > > > > > > > > > > I was thinking that the next release off branch-2.0 could be 2.1.0. It > > has > > > 70+ commits including a big boost in perf. It feels more like a minor > > > release than it does a point release. > > > > > > Branch 3.0.0 rather than 2.1.0 Duo? > > > > > > S > > > > > > > > > > > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > > > > > > > Plan to cut branch-2.1 at the end of May. Will consider the status > of > > > the > > > > > new features at that time to determine what will be released with > > 2.1.x > > > > > release line. > > > > > > > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > > > > > > > >> Big big big +1 > > > > >> > > > > >> (Came in to say just this but you beat me to it :D) > > > > >> > > > > >> > > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > > > > >> > > > > >>> Let's do big features in 3.0.0 only. > > > > >>> > > > > >>> Ideally there will no big new features for a minor release, so > that > > > we > > > > >>> can > > > > >>> move the stable pointer to newer minor versions quickly and > retire > > > the > > > > >>> old > > > > >>> branches. It will be a nightmare if we have lots of active minor > > > > release > > > > >>> lines... > > > > >>> > > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : > > > > >>> > > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > > > > experiment > > > > feature in 2.1? > > > > > > > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) >: > > > > > > > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai >: > > > > > > > > > > As I volunteered to be the release manager for the 2.1 release > > line > > > > >>> > > > > >> so > > > > > > > > > let > > > > >> > > > > >>> me bring this up. > > > > >>> > > > > >> +1 to Duo be RM of 2.1 release. > > > > >> > > > > >> disabled from 2.0.0 release, for example, serial replication, > > and > > > in > > > > >>> > > > > >> memory compaction > > > > >> IIRC, in memory compaction is enabled in 2.0 and the default > > > policy > > > > is > > > > >> BASIC. (please correct me if I misunderstand something.) > > > > >> > > > > >> We disabled it by default in the end due to some performance > > > > issues... > > > > > > > > > > > > > > >> For the 2.1 release line, I would like to define it as the > > 'real' > > > > 2.x > > > > >>> > > > > >> Seems the release date between 2.0 and 2.1 will be very close. > > Is > > > it > > > > >> related to our new release plan? (IIRC, Andrew had suggested > > some > > > > >> great > > > > >> release plan based time. But I fail to find the thread...) > > > > >> > > > > >> And for the 3.0.0 release, I think the new features should be > > > > decided > > > > >>> > > > > >> ASAP. > > > > >> > > > > >>> We need to avoid the same thing happens again, i.e, spending > 2 > > > > years > > > > >>> > > > > >> to > > > > > > > > > release a major version... > > > > >>> > > > > >> agreed! > > > > >> > > > > >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) > > > > wrote: > > > > >> > > > > >>> As I volunteered to be the release manager for the 2.1 > release > > > line > > > > >>> > > > > >> so > > > > > > > > > let > > > > >> > > > > >>> me bring this up. > > > > >>
Re: On the 2.1.0 and 3.0.0 release
On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang) wrote: > What;s your plan sir? Branch branch-2.1 from branch-2.0? > > Its a suggestion. I like Andrew's notion that we left-shift how we have been thinking about version numbers; that we releases tend toward minor increments rather than patch increments as we have been doing up to this. If we are going to act on Andrew's suggestion, now is the time to do it. 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug and perf improvements only. We already have enough to define a substantial 3.0.0 IMO what with serial replication and HBASE-20312 CCSMap. I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to ship. Meantime we accumulate a mountain of testing, perf, and whatever else tech debt. What do folks think? Thanks, S > 2018-06-04 11:50 GMT+08:00 Stack : > > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) > > wrote: > > > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished > > features > > > will be disabled by default or purged from branch-2.1 and target to 2.2 > > > release. > > > > > > > > I was thinking that the next release off branch-2.0 could be 2.1.0. It > has > > 70+ commits including a big boost in perf. It feels more like a minor > > release than it does a point release. > > > > Branch 3.0.0 rather than 2.1.0 Duo? > > > > S > > > > > > > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > > > > > Plan to cut branch-2.1 at the end of May. Will consider the status of > > the > > > > new features at that time to determine what will be released with > 2.1.x > > > > release line. > > > > > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > > > > > >> Big big big +1 > > > >> > > > >> (Came in to say just this but you beat me to it :D) > > > >> > > > >> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > > > >> > > > >>> Let's do big features in 3.0.0 only. > > > >>> > > > >>> Ideally there will no big new features for a minor release, so that > > we > > > >>> can > > > >>> move the stable pointer to newer minor versions quickly and retire > > the > > > >>> old > > > >>> branches. It will be a nightmare if we have lots of active minor > > > release > > > >>> lines... > > > >>> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : > > > >>> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > > > experiment > > > feature in 2.1? > > > > > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : > > > > > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : > > > > > > > > As I volunteered to be the release manager for the 2.1 release > line > > > >>> > > > >> so > > > > > > > let > > > >> > > > >>> me bring this up. > > > >>> > > > >> +1 to Duo be RM of 2.1 release. > > > >> > > > >> disabled from 2.0.0 release, for example, serial replication, > and > > in > > > >>> > > > >> memory compaction > > > >> IIRC, in memory compaction is enabled in 2.0 and the default > > policy > > > is > > > >> BASIC. (please correct me if I misunderstand something.) > > > >> > > > >> We disabled it by default in the end due to some performance > > > issues... > > > > > > > > > > > >> For the 2.1 release line, I would like to define it as the > 'real' > > > 2.x > > > >>> > > > >> Seems the release date between 2.0 and 2.1 will be very close. > Is > > it > > > >> related to our new release plan? (IIRC, Andrew had suggested > some > > > >> great > > > >> release plan based time. But I fail to find the thread...) > > > >> > > > >> And for the 3.0.0 release, I think the new features should be > > > decided > > > >>> > > > >> ASAP. > > > >> > > > >>> We need to avoid the same thing happens again, i.e, spending 2 > > > years > > > >>> > > > >> to > > > > > > > release a major version... > > > >>> > > > >> agreed! > > > >> > > > >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) > > > wrote: > > > >> > > > >>> As I volunteered to be the release manager for the 2.1 release > > line > > > >>> > > > >> so > > > > > > > let > > > >> > > > >>> me bring this up. > > > >>> > > > >>> For the 2.1 release line, I would like to define it as the > 'real' > > > 2.x > > > >>> version of HBase. It should include the features which are > > reverted > > > >>> > > > >> or > > > > > > > disabled from 2.0.0 release, for example, serial replication, and > > in > > > >>> > > > >> memory > > > >> > > > >>> compaction. And also, the performance issues. And no more new > > > >>> > > > >> features. > > > > > > > If > > > >> > > > >>> no objections, I will start the release work soon. > > > >>> > > > >>>
Re: On the 2.1.0 and 3.0.0 release
What;s your plan sir? Branch branch-2.1 from branch-2.0? 2018-06-04 11:50 GMT+08:00 Stack : > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) > wrote: > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished > features > > will be disabled by default or purged from branch-2.1 and target to 2.2 > > release. > > > > > I was thinking that the next release off branch-2.0 could be 2.1.0. It has > 70+ commits including a big boost in perf. It feels more like a minor > release than it does a point release. > > Branch 3.0.0 rather than 2.1.0 Duo? > > S > > > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > > > Plan to cut branch-2.1 at the end of May. Will consider the status of > the > > > new features at that time to determine what will be released with 2.1.x > > > release line. > > > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > > > >> Big big big +1 > > >> > > >> (Came in to say just this but you beat me to it :D) > > >> > > >> > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > > >> > > >>> Let's do big features in 3.0.0 only. > > >>> > > >>> Ideally there will no big new features for a minor release, so that > we > > >>> can > > >>> move the stable pointer to newer minor versions quickly and retire > the > > >>> old > > >>> branches. It will be a nightmare if we have lots of active minor > > release > > >>> lines... > > >>> > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : > > >>> > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > > experiment > > feature in 2.1? > > > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : > > > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : > > > > > > As I volunteered to be the release manager for the 2.1 release line > > >>> > > >> so > > > > > let > > >> > > >>> me bring this up. > > >>> > > >> +1 to Duo be RM of 2.1 release. > > >> > > >> disabled from 2.0.0 release, for example, serial replication, and > in > > >>> > > >> memory compaction > > >> IIRC, in memory compaction is enabled in 2.0 and the default > policy > > is > > >> BASIC. (please correct me if I misunderstand something.) > > >> > > >> We disabled it by default in the end due to some performance > > issues... > > > > > > > > >> For the 2.1 release line, I would like to define it as the 'real' > > 2.x > > >>> > > >> Seems the release date between 2.0 and 2.1 will be very close. Is > it > > >> related to our new release plan? (IIRC, Andrew had suggested some > > >> great > > >> release plan based time. But I fail to find the thread...) > > >> > > >> And for the 3.0.0 release, I think the new features should be > > decided > > >>> > > >> ASAP. > > >> > > >>> We need to avoid the same thing happens again, i.e, spending 2 > > years > > >>> > > >> to > > > > > release a major version... > > >>> > > >> agreed! > > >> > > >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) > > wrote: > > >> > > >>> As I volunteered to be the release manager for the 2.1 release > line > > >>> > > >> so > > > > > let > > >> > > >>> me bring this up. > > >>> > > >>> For the 2.1 release line, I would like to define it as the 'real' > > 2.x > > >>> version of HBase. It should include the features which are > reverted > > >>> > > >> or > > > > > disabled from 2.0.0 release, for example, serial replication, and > in > > >>> > > >> memory > > >> > > >>> compaction. And also, the performance issues. And no more new > > >>> > > >> features. > > > > > If > > >> > > >>> no objections, I will start the release work soon. > > >>> > > >>> And for the 3.0.0 release, I think the new features should be > > decided > > >>> > > >> ASAP. > > >> > > >>> We need to avoid the same thing happens again, i.e, spending 2 > > years > > >>> > > >> to > > > > > release a major version... > > >>> > > >>> For now, the new features > > >>> Synchronous replication > > >>> CCSMap > > >>> Backup > > >>> Spark connector(is it still active?) > > >>> > > >>> And I suggest that we include this: > > >>> The read path refactoring(HBASE-20525) > > >>> > > >>> Suggestions are welcomed. > > >>> > > >>> Thanks. > > >>> > > >>> > > >> > > > > > > > >>> > > > > > >
Re: On the 2.1.0 and 3.0.0 release
On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) wrote: > Will cut the 2.1 branch tomorrow if no objections. The unfinished features > will be disabled by default or purged from branch-2.1 and target to 2.2 > release. > > I was thinking that the next release off branch-2.0 could be 2.1.0. It has 70+ commits including a big boost in perf. It feels more like a minor release than it does a point release. Branch 3.0.0 rather than 2.1.0 Duo? S > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > Plan to cut branch-2.1 at the end of May. Will consider the status of the > > new features at that time to determine what will be released with 2.1.x > > release line. > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > >> Big big big +1 > >> > >> (Came in to say just this but you beat me to it :D) > >> > >> > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > >> > >>> Let's do big features in 3.0.0 only. > >>> > >>> Ideally there will no big new features for a minor release, so that we > >>> can > >>> move the stable pointer to newer minor versions quickly and retire the > >>> old > >>> branches. It will be a nightmare if we have lots of active minor > release > >>> lines... > >>> > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : > >>> > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > experiment > feature in 2.1? > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : > > > > As I volunteered to be the release manager for the 2.1 release line > >>> > >> so > > > let > >> > >>> me bring this up. > >>> > >> +1 to Duo be RM of 2.1 release. > >> > >> disabled from 2.0.0 release, for example, serial replication, and in > >>> > >> memory compaction > >> IIRC, in memory compaction is enabled in 2.0 and the default policy > is > >> BASIC. (please correct me if I misunderstand something.) > >> > >> We disabled it by default in the end due to some performance > issues... > > > > > >> For the 2.1 release line, I would like to define it as the 'real' > 2.x > >>> > >> Seems the release date between 2.0 and 2.1 will be very close. Is it > >> related to our new release plan? (IIRC, Andrew had suggested some > >> great > >> release plan based time. But I fail to find the thread...) > >> > >> And for the 3.0.0 release, I think the new features should be > decided > >>> > >> ASAP. > >> > >>> We need to avoid the same thing happens again, i.e, spending 2 > years > >>> > >> to > > > release a major version... > >>> > >> agreed! > >> > >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) > wrote: > >> > >>> As I volunteered to be the release manager for the 2.1 release line > >>> > >> so > > > let > >> > >>> me bring this up. > >>> > >>> For the 2.1 release line, I would like to define it as the 'real' > 2.x > >>> version of HBase. It should include the features which are reverted > >>> > >> or > > > disabled from 2.0.0 release, for example, serial replication, and in > >>> > >> memory > >> > >>> compaction. And also, the performance issues. And no more new > >>> > >> features. > > > If > >> > >>> no objections, I will start the release work soon. > >>> > >>> And for the 3.0.0 release, I think the new features should be > decided > >>> > >> ASAP. > >> > >>> We need to avoid the same thing happens again, i.e, spending 2 > years > >>> > >> to > > > release a major version... > >>> > >>> For now, the new features > >>> Synchronous replication > >>> CCSMap > >>> Backup > >>> Spark connector(is it still active?) > >>> > >>> And I suggest that we include this: > >>> The read path refactoring(HBASE-20525) > >>> > >>> Suggestions are welcomed. > >>> > >>> Thanks. > >>> > >>> > >> > > > > >>> > > >
Re: On the 2.1.0 and 3.0.0 release
Also, can you document 2.0 to 2.1? (even if there are no special steps) :) Nice to see you continuing to push on 2.1, Duo! On 6/3/18 10:09 PM, 张铎(Duo Zhang) wrote: Serial replication will be fine. And also I will do some work on document how to rolling upgrade from 1.x to 2.1. 2018-06-04 9:55 GMT+08:00 Mike Drob : Do you have an idea already of which features are making the cut? On Sun, Jun 3, 2018, 7:36 PM 张铎(Duo Zhang) wrote: Will cut the 2.1 branch tomorrow if no objections. The unfinished features will be disabled by default or purged from branch-2.1 and target to 2.2 release. 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : Plan to cut branch-2.1 at the end of May. Will consider the status of the new features at that time to determine what will be released with 2.1.x release line. 2018-05-08 10:16 GMT+08:00 Josh Elser : Big big big +1 (Came in to say just this but you beat me to it :D) On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: Let's do big features in 3.0.0 only. Ideally there will no big new features for a minor release, so that we can move the stable pointer to newer minor versions quickly and retire the old branches. It will be a nightmare if we have lots of active minor release lines... 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : Why 2.1 doesn't contatin synchronous replication? This can be a experiment feature in 2.1? 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : As I volunteered to be the release manager for the 2.1 release line so let me bring this up. +1 to Duo be RM of 2.1 release. disabled from 2.0.0 release, for example, serial replication, and in memory compaction IIRC, in memory compaction is enabled in 2.0 and the default policy is BASIC. (please correct me if I misunderstand something.) We disabled it by default in the end due to some performance issues... For the 2.1 release line, I would like to define it as the 'real' 2.x Seems the release date between 2.0 and 2.1 will be very close. Is it related to our new release plan? (IIRC, Andrew had suggested some great release plan based time. But I fail to find the thread...) And for the 3.0.0 release, I think the new features should be decided ASAP. We need to avoid the same thing happens again, i.e, spending 2 years to release a major version... agreed! On 2018/05/07 00:52:07, 张铎(Duo Zhang) wrote: As I volunteered to be the release manager for the 2.1 release line so let me bring this up. For the 2.1 release line, I would like to define it as the 'real' 2.x version of HBase. It should include the features which are reverted or disabled from 2.0.0 release, for example, serial replication, and in memory compaction. And also, the performance issues. And no more new features. If no objections, I will start the release work soon. And for the 3.0.0 release, I think the new features should be decided ASAP. We need to avoid the same thing happens again, i.e, spending 2 years to release a major version... For now, the new features Synchronous replication CCSMap Backup Spark connector(is it still active?) And I suggest that we include this: The read path refactoring(HBASE-20525) Suggestions are welcomed. Thanks.
[jira] [Created] (HBASE-20678) NPE in ReplicationSourceManager#NodeFailoverWorker
Guanghao Zhang created HBASE-20678:
--
Summary: NPE in ReplicationSourceManager#NodeFailoverWorker
Key: HBASE-20678
URL: https://issues.apache.org/jira/browse/HBASE-20678
Project: HBase
Issue Type: Umbrella
Reporter: Guanghao Zhang
2018-06-04 10:28:43,362 INFO [ReplicationExecutor-0]
replication.ZKReplicationQueueStorage(432): Claim queue queueId=1 from
hao-optiplex-7050,38491,1528079278158 to hao-optiplex-7050,39931,1528079278272
failed with org.apache.zookeeper.KeeperException$NoNodeException:
KeeperErrorCode = NoNode, someone else took the log?
Exception in thread "ReplicationExecutor-0" java.lang.NullPointerException
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager$NodeFailoverWorker.run(ReplicationSourceManager.java:858)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
ZKReplicationQueueStorage's claimQueue method may return null when got
NoNodeException.
{code:java}
Pair> peer = queueStorage.claimQueue(deadRS,
queues.get(ThreadLocalRandom.current().nextInt(queues.size())),
server.getServerName());
long sleep = sleepBeforeFailover / 2;
if (!peer.getSecond().isEmpty()) {
newQueues.put(peer.getFirst(), peer.getSecond());
sleep = sleepBeforeFailover;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: On the 2.1.0 and 3.0.0 release
Serial replication will be fine. And also I will do some work on document how to rolling upgrade from 1.x to 2.1. 2018-06-04 9:55 GMT+08:00 Mike Drob : > Do you have an idea already of which features are making the cut? > > On Sun, Jun 3, 2018, 7:36 PM 张铎(Duo Zhang) wrote: > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished > features > > will be disabled by default or purged from branch-2.1 and target to 2.2 > > release. > > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > > > Plan to cut branch-2.1 at the end of May. Will consider the status of > the > > > new features at that time to determine what will be released with 2.1.x > > > release line. > > > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > > > >> Big big big +1 > > >> > > >> (Came in to say just this but you beat me to it :D) > > >> > > >> > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > > >> > > >>> Let's do big features in 3.0.0 only. > > >>> > > >>> Ideally there will no big new features for a minor release, so that > we > > >>> can > > >>> move the stable pointer to newer minor versions quickly and retire > the > > >>> old > > >>> branches. It will be a nightmare if we have lots of active minor > > release > > >>> lines... > > >>> > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : > > >>> > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > > experiment > > feature in 2.1? > > > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : > > > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : > > > > > > As I volunteered to be the release manager for the 2.1 release line > > >>> > > >> so > > > > > let > > >> > > >>> me bring this up. > > >>> > > >> +1 to Duo be RM of 2.1 release. > > >> > > >> disabled from 2.0.0 release, for example, serial replication, and > in > > >>> > > >> memory compaction > > >> IIRC, in memory compaction is enabled in 2.0 and the default > policy > > is > > >> BASIC. (please correct me if I misunderstand something.) > > >> > > >> We disabled it by default in the end due to some performance > > issues... > > > > > > > > >> For the 2.1 release line, I would like to define it as the 'real' > > 2.x > > >>> > > >> Seems the release date between 2.0 and 2.1 will be very close. Is > it > > >> related to our new release plan? (IIRC, Andrew had suggested some > > >> great > > >> release plan based time. But I fail to find the thread...) > > >> > > >> And for the 3.0.0 release, I think the new features should be > > decided > > >>> > > >> ASAP. > > >> > > >>> We need to avoid the same thing happens again, i.e, spending 2 > > years > > >>> > > >> to > > > > > release a major version... > > >>> > > >> agreed! > > >> > > >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) > > wrote: > > >> > > >>> As I volunteered to be the release manager for the 2.1 release > line > > >>> > > >> so > > > > > let > > >> > > >>> me bring this up. > > >>> > > >>> For the 2.1 release line, I would like to define it as the 'real' > > 2.x > > >>> version of HBase. It should include the features which are > reverted > > >>> > > >> or > > > > > disabled from 2.0.0 release, for example, serial replication, and > in > > >>> > > >> memory > > >> > > >>> compaction. And also, the performance issues. And no more new > > >>> > > >> features. > > > > > If > > >> > > >>> no objections, I will start the release work soon. > > >>> > > >>> And for the 3.0.0 release, I think the new features should be > > decided > > >>> > > >> ASAP. > > >> > > >>> We need to avoid the same thing happens again, i.e, spending 2 > > years > > >>> > > >> to > > > > > release a major version... > > >>> > > >>> For now, the new features > > >>> Synchronous replication > > >>> CCSMap > > >>> Backup > > >>> Spark connector(is it still active?) > > >>> > > >>> And I suggest that we include this: > > >>> The read path refactoring(HBASE-20525) > > >>> > > >>> Suggestions are welcomed. > > >>> > > >>> Thanks. > > >>> > > >>> > > >> > > > > > > > >>> > > > > > >
Re: On the 2.1.0 and 3.0.0 release
Do you have an idea already of which features are making the cut? On Sun, Jun 3, 2018, 7:36 PM 张铎(Duo Zhang) wrote: > Will cut the 2.1 branch tomorrow if no objections. The unfinished features > will be disabled by default or purged from branch-2.1 and target to 2.2 > release. > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > Plan to cut branch-2.1 at the end of May. Will consider the status of the > > new features at that time to determine what will be released with 2.1.x > > release line. > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > >> Big big big +1 > >> > >> (Came in to say just this but you beat me to it :D) > >> > >> > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > >> > >>> Let's do big features in 3.0.0 only. > >>> > >>> Ideally there will no big new features for a minor release, so that we > >>> can > >>> move the stable pointer to newer minor versions quickly and retire the > >>> old > >>> branches. It will be a nightmare if we have lots of active minor > release > >>> lines... > >>> > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : > >>> > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > experiment > feature in 2.1? > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : > > > > As I volunteered to be the release manager for the 2.1 release line > >>> > >> so > > > let > >> > >>> me bring this up. > >>> > >> +1 to Duo be RM of 2.1 release. > >> > >> disabled from 2.0.0 release, for example, serial replication, and in > >>> > >> memory compaction > >> IIRC, in memory compaction is enabled in 2.0 and the default policy > is > >> BASIC. (please correct me if I misunderstand something.) > >> > >> We disabled it by default in the end due to some performance > issues... > > > > > >> For the 2.1 release line, I would like to define it as the 'real' > 2.x > >>> > >> Seems the release date between 2.0 and 2.1 will be very close. Is it > >> related to our new release plan? (IIRC, Andrew had suggested some > >> great > >> release plan based time. But I fail to find the thread...) > >> > >> And for the 3.0.0 release, I think the new features should be > decided > >>> > >> ASAP. > >> > >>> We need to avoid the same thing happens again, i.e, spending 2 > years > >>> > >> to > > > release a major version... > >>> > >> agreed! > >> > >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) > wrote: > >> > >>> As I volunteered to be the release manager for the 2.1 release line > >>> > >> so > > > let > >> > >>> me bring this up. > >>> > >>> For the 2.1 release line, I would like to define it as the 'real' > 2.x > >>> version of HBase. It should include the features which are reverted > >>> > >> or > > > disabled from 2.0.0 release, for example, serial replication, and in > >>> > >> memory > >> > >>> compaction. And also, the performance issues. And no more new > >>> > >> features. > > > If > >> > >>> no objections, I will start the release work soon. > >>> > >>> And for the 3.0.0 release, I think the new features should be > decided > >>> > >> ASAP. > >> > >>> We need to avoid the same thing happens again, i.e, spending 2 > years > >>> > >> to > > > release a major version... > >>> > >>> For now, the new features > >>> Synchronous replication > >>> CCSMap > >>> Backup > >>> Spark connector(is it still active?) > >>> > >>> And I suggest that we include this: > >>> The read path refactoring(HBASE-20525) > >>> > >>> Suggestions are welcomed. > >>> > >>> Thanks. > >>> > >>> > >> > > > > >>> > > >
Re: On the 2.1.0 and 3.0.0 release
Will cut the 2.1 branch tomorrow if no objections. The unfinished features will be disabled by default or purged from branch-2.1 and target to 2.2 release. 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > Plan to cut branch-2.1 at the end of May. Will consider the status of the > new features at that time to determine what will be released with 2.1.x > release line. > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > >> Big big big +1 >> >> (Came in to say just this but you beat me to it :D) >> >> >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: >> >>> Let's do big features in 3.0.0 only. >>> >>> Ideally there will no big new features for a minor release, so that we >>> can >>> move the stable pointer to newer minor versions quickly and retire the >>> old >>> branches. It will be a nightmare if we have lots of active minor release >>> lines... >>> >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang : >>> >>> Why 2.1 doesn't contatin synchronous replication? This can be a experiment feature in 2.1? 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) : 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai : > > As I volunteered to be the release manager for the 2.1 release line >>> >> so > let >> >>> me bring this up. >>> >> +1 to Duo be RM of 2.1 release. >> >> disabled from 2.0.0 release, for example, serial replication, and in >>> >> memory compaction >> IIRC, in memory compaction is enabled in 2.0 and the default policy is >> BASIC. (please correct me if I misunderstand something.) >> >> We disabled it by default in the end due to some performance issues... > > >> For the 2.1 release line, I would like to define it as the 'real' 2.x >>> >> Seems the release date between 2.0 and 2.1 will be very close. Is it >> related to our new release plan? (IIRC, Andrew had suggested some >> great >> release plan based time. But I fail to find the thread...) >> >> And for the 3.0.0 release, I think the new features should be decided >>> >> ASAP. >> >>> We need to avoid the same thing happens again, i.e, spending 2 years >>> >> to > release a major version... >>> >> agreed! >> >> On 2018/05/07 00:52:07, 张铎(Duo Zhang) wrote: >> >>> As I volunteered to be the release manager for the 2.1 release line >>> >> so > let >> >>> me bring this up. >>> >>> For the 2.1 release line, I would like to define it as the 'real' 2.x >>> version of HBase. It should include the features which are reverted >>> >> or > disabled from 2.0.0 release, for example, serial replication, and in >>> >> memory >> >>> compaction. And also, the performance issues. And no more new >>> >> features. > If >> >>> no objections, I will start the release work soon. >>> >>> And for the 3.0.0 release, I think the new features should be decided >>> >> ASAP. >> >>> We need to avoid the same thing happens again, i.e, spending 2 years >>> >> to > release a major version... >>> >>> For now, the new features >>> Synchronous replication >>> CCSMap >>> Backup >>> Spark connector(is it still active?) >>> >>> And I suggest that we include this: >>> The read path refactoring(HBASE-20525) >>> >>> Suggestions are welcomed. >>> >>> Thanks. >>> >>> >> > >>> >
[jira] [Created] (HBASE-20677) Backport HBASE-20566 'Creating a system table after enabling rsgroup feature puts region into RIT ' to branch-2
Ted Yu created HBASE-20677: -- Summary: Backport HBASE-20566 'Creating a system table after enabling rsgroup feature puts region into RIT ' to branch-2 Key: HBASE-20677 URL: https://issues.apache.org/jira/browse/HBASE-20677 Project: HBase Issue Type: Task Reporter: Ted Yu After HBASE-20566 was integrated into master, HBASE-20595 removed the concept of 'special tables' from rsgroups. This task is to backport the fix to branch-2. TestRSGroups#testRSGroupsWithHBaseQuota would be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Apache HBase 1.3.2.1RC0
+1 Built from source Ran test suite using Jdk 8 which passed. On Sat, Jun 2, 2018 at 2:26 PM, Josh Elser wrote: > Hi, > > Please vote to approve the following as Apache HBase 1.3.2.1 > > https://dist.apache.org/repos/dist/dev/hbase/1.3.2.1RC0/ > > Per usual, there is a source release as well as a convenience binary > > This is built with JDK7 from the commit: https://git-wip-us.apache.org/ > repos/asf?p=hbase.git;a=commit;h=bf25c1cb7221178388baaa58f0b16a408e151a69 > (there is a corresponding tag "1.3.2.1RC0" for convenience) > > hbase-1.3.2.1-bin.tar.gz: 1D CB 27 E0 B0 56 28 B8 BE C7 41 03 2E B5 D3 31 > hbase-1.3.2.1-src.tar.gz: 47 99 46 3C 2B E2 59 9B 5B 8B 2F 16 81 53 6B FE > hbase-1.3.2.1-bin.tar.gz: 16EB62DA D4EA40F6 DD8747CF 6A49678E D1A4A53E > B3A9E67D > C53A89F1 471D1DC5 5147E5CA D1AED8B0 B22A01F5 > C1F6F6CA > 4B4E9562 61CDA9B6 91D94C16 26593AFB > hbase-1.3.2.1-src.tar.gz: 63C55C02 DB27461E 2C006758 329EC21E E14823E3 > 9080105B > 43FA6EF2 05BD81A3 D526E2AC 6EAE0FE9 1C3103F4 > 20B8457F > 3C94EF73 5B3CB18C 85B7E0AB 4311CAA4 > > This vote will be open for at least 72 hours (2018/06/05 2130 UTC). > > - Josh (on behalf of the HBase PMC) >
