[jira] [Created] (HBASE-24408) Introduce a general 'local region' to store data on master
Duo Zhang created HBASE-24408: - Summary: Introduce a general 'local region' to store data on master Key: HBASE-24408 URL: https://issues.apache.org/jira/browse/HBASE-24408 Project: HBase Issue Type: Task Reporter: Duo Zhang We already have a local region to store the procedure data and when implementing HBASE-11288, splittable meta, we are thinking of also storing the data for root table in a local region. Now in the patch for HBASE-24388, we introduced another local region to store the data for root table, but maybe it is better to store the procedure data and root table together in a single region(with different families). And this should be done before 2.3.0, to prevent shipping the procedure store region out in a release. Set it a blocker for 2.3.0. Patch will be available soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24407) Correct the comment of clusterRegionLocationMocks in TestStochasticLoadBalancer
Zheng Wang created HBASE-24407: -- Summary: Correct the comment of clusterRegionLocationMocks in TestStochasticLoadBalancer Key: HBASE-24407 URL: https://issues.apache.org/jira/browse/HBASE-24407 Project: HBase Issue Type: Improvement Components: Balancer Reporter: Zheng Wang Assignee: Zheng Wang It's a little bit inaccurate in comment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Delete old branches
I like the idea of an old/ or eom/ prefix for old release lines. I'm also fine with deleting old release lines. For feature branches I think case by case unless the feature has merged. Maybe a discuss for more complicated feature branches that are unlikely to merge (0.89-fb hydrabase, etc). We can always tag these or put them in the "this isn't being looked at" prefix mentioned above. On Wed, May 20, 2020, 20:23 Andrew Purtell wrote: > What we do at $dayjob is rename old branches old/*. > So we could rename EOL branches this way? E.g. > > for branch in branch-2.1 ... ; do > git checkout $branch && > git branch -m old/$branch && > git push $origin old/$branch :$branch > done > > > On Wed, May 20, 2020 at 6:21 PM Nick Dimiduk wrote: > > > Why remove old/unused branches? To keep our garden tidy. They’re > > distracting at best, confusing at worst. For old release line branches, > > it’s not clear to a casual committer which branches need to receive a > back > > port. It’s clear if the EOL branches are gone. > > > > On Wed, May 20, 2020 at 18:06 Guanghao Zhang wrote: > > > > > +1 for remove feature branches and start a case-by-case discussion for > > > "others". > > > > > > And for branchs of old release line, what's the harm if keep them? I > > > thought we don't need to remove them. > > > > > > Thanks. > > > > > > 张铎(Duo Zhang) 于2020年5月21日周四 上午8:14写道： > > > > > > > What is the benefit? > > > > > > > > Nick Dimiduk 于2020年5月21日 周四07:31写道： > > > > > > > > > Heya, > > > > > > > > > > We have lots of branches hanging around in git. These appear to be > > > > > 1. branches for old release lines (i.e., 0.90), > > > > > 2. feature branches (that are potentially stale, i.e., > HBASE-11288), > > > > > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > > > > > > > > > Can we decide it's okay to delete some of these? > > > > > > > > > > For (1), all of our release tags, going back to 0.1, are preserved. > > > > There's > > > > > no benefit to keeping these. > > > > > > > > > > For (2), I think there's no discussion required, just someone to go > > > check > > > > > each Jira ID, and delete any that are closed, maybe with a comment > on > > > the > > > > > Jira first. Maybe this could be automated? > > > > > > > > > > For (3), I suppose we need a case-by-case discussion? Maybe there > are > > > > > categories of these that can be resolved in blocks. > > > > > > > > > > Thanks, > > > > > Nick > > > > > > > > > > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
Re: [DISCUSS] Delete old branches
Set read-only for EOL branches? Similar to protected branch in gitlab. Andrew Purtell 于2020年5月21日周四 上午9:23写道： > What we do at $dayjob is rename old branches old/*. > So we could rename EOL branches this way? E.g. > > for branch in branch-2.1 ... ; do > git checkout $branch && > git branch -m old/$branch && > git push $origin old/$branch :$branch > done > > > On Wed, May 20, 2020 at 6:21 PM Nick Dimiduk wrote: > > > Why remove old/unused branches? To keep our garden tidy. They’re > > distracting at best, confusing at worst. For old release line branches, > > it’s not clear to a casual committer which branches need to receive a > back > > port. It’s clear if the EOL branches are gone. > > > > On Wed, May 20, 2020 at 18:06 Guanghao Zhang wrote: > > > > > +1 for remove feature branches and start a case-by-case discussion for > > > "others". > > > > > > And for branchs of old release line, what's the harm if keep them? I > > > thought we don't need to remove them. > > > > > > Thanks. > > > > > > 张铎(Duo Zhang) 于2020年5月21日周四 上午8:14写道： > > > > > > > What is the benefit? > > > > > > > > Nick Dimiduk 于2020年5月21日 周四07:31写道： > > > > > > > > > Heya, > > > > > > > > > > We have lots of branches hanging around in git. These appear to be > > > > > 1. branches for old release lines (i.e., 0.90), > > > > > 2. feature branches (that are potentially stale, i.e., > HBASE-11288), > > > > > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > > > > > > > > > Can we decide it's okay to delete some of these? > > > > > > > > > > For (1), all of our release tags, going back to 0.1, are preserved. > > > > There's > > > > > no benefit to keeping these. > > > > > > > > > > For (2), I think there's no discussion required, just someone to go > > > check > > > > > each Jira ID, and delete any that are closed, maybe with a comment > on > > > the > > > > > Jira first. Maybe this could be automated? > > > > > > > > > > For (3), I suppose we need a case-by-case discussion? Maybe there > are > > > > > categories of these that can be resolved in blocks. > > > > > > > > > > Thanks, > > > > > Nick > > > > > > > > > > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
Re: [DISCUSS] Delete old branches
What we do at $dayjob is rename old branches old/*. So we could rename EOL branches this way? E.g. for branch in branch-2.1 ... ; do git checkout $branch && git branch -m old/$branch && git push $origin old/$branch :$branch done On Wed, May 20, 2020 at 6:21 PM Nick Dimiduk wrote: > Why remove old/unused branches? To keep our garden tidy. They’re > distracting at best, confusing at worst. For old release line branches, > it’s not clear to a casual committer which branches need to receive a back > port. It’s clear if the EOL branches are gone. > > On Wed, May 20, 2020 at 18:06 Guanghao Zhang wrote: > > > +1 for remove feature branches and start a case-by-case discussion for > > "others". > > > > And for branchs of old release line, what's the harm if keep them? I > > thought we don't need to remove them. > > > > Thanks. > > > > 张铎(Duo Zhang) 于2020年5月21日周四 上午8:14写道： > > > > > What is the benefit? > > > > > > Nick Dimiduk 于2020年5月21日 周四07:31写道： > > > > > > > Heya, > > > > > > > > We have lots of branches hanging around in git. These appear to be > > > > 1. branches for old release lines (i.e., 0.90), > > > > 2. feature branches (that are potentially stale, i.e., HBASE-11288), > > > > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > > > > > > > Can we decide it's okay to delete some of these? > > > > > > > > For (1), all of our release tags, going back to 0.1, are preserved. > > > There's > > > > no benefit to keeping these. > > > > > > > > For (2), I think there's no discussion required, just someone to go > > check > > > > each Jira ID, and delete any that are closed, maybe with a comment on > > the > > > > Jira first. Maybe this could be automated? > > > > > > > > For (3), I suppose we need a case-by-case discussion? Maybe there are > > > > categories of these that can be resolved in blocks. > > > > > > > > Thanks, > > > > Nick > > > > > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] Delete old branches
Why remove old/unused branches? To keep our garden tidy. They’re distracting at best, confusing at worst. For old release line branches, it’s not clear to a casual committer which branches need to receive a back port. It’s clear if the EOL branches are gone. On Wed, May 20, 2020 at 18:06 Guanghao Zhang wrote: > +1 for remove feature branches and start a case-by-case discussion for > "others". > > And for branchs of old release line, what's the harm if keep them? I > thought we don't need to remove them. > > Thanks. > > 张铎(Duo Zhang) 于2020年5月21日周四 上午8:14写道： > > > What is the benefit? > > > > Nick Dimiduk 于2020年5月21日 周四07:31写道： > > > > > Heya, > > > > > > We have lots of branches hanging around in git. These appear to be > > > 1. branches for old release lines (i.e., 0.90), > > > 2. feature branches (that are potentially stale, i.e., HBASE-11288), > > > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > > > > > Can we decide it's okay to delete some of these? > > > > > > For (1), all of our release tags, going back to 0.1, are preserved. > > There's > > > no benefit to keeping these. > > > > > > For (2), I think there's no discussion required, just someone to go > check > > > each Jira ID, and delete any that are closed, maybe with a comment on > the > > > Jira first. Maybe this could be automated? > > > > > > For (3), I suppose we need a case-by-case discussion? Maybe there are > > > categories of these that can be resolved in blocks. > > > > > > Thanks, > > > Nick > > > > > >
Re: [DISCUSS] Delete old branches
+1 for remove feature branches and start a case-by-case discussion for "others". And for branchs of old release line, what's the harm if keep them? I thought we don't need to remove them. Thanks. 张铎(Duo Zhang) 于2020年5月21日周四 上午8:14写道： > What is the benefit? > > Nick Dimiduk 于2020年5月21日 周四07:31写道： > > > Heya, > > > > We have lots of branches hanging around in git. These appear to be > > 1. branches for old release lines (i.e., 0.90), > > 2. feature branches (that are potentially stale, i.e., HBASE-11288), > > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > > > Can we decide it's okay to delete some of these? > > > > For (1), all of our release tags, going back to 0.1, are preserved. > There's > > no benefit to keeping these. > > > > For (2), I think there's no discussion required, just someone to go check > > each Jira ID, and delete any that are closed, maybe with a comment on the > > Jira first. Maybe this could be automated? > > > > For (3), I suppose we need a case-by-case discussion? Maybe there are > > categories of these that can be resolved in blocks. > > > > Thanks, > > Nick > > >
Re: [DISCUSS] Delete old branches
What is the benefit? Nick Dimiduk 于2020年5月21日 周四07:31写道： > Heya, > > We have lots of branches hanging around in git. These appear to be > 1. branches for old release lines (i.e., 0.90), > 2. feature branches (that are potentially stale, i.e., HBASE-11288), > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > Can we decide it's okay to delete some of these? > > For (1), all of our release tags, going back to 0.1, are preserved. There's > no benefit to keeping these. > > For (2), I think there's no discussion required, just someone to go check > each Jira ID, and delete any that are closed, maybe with a comment on the > Jira first. Maybe this could be automated? > > For (3), I suppose we need a case-by-case discussion? Maybe there are > categories of these that can be resolved in blocks. > > Thanks, > Nick >
[DISCUSS] Delete old branches
Heya, We have lots of branches hanging around in git. These appear to be 1. branches for old release lines (i.e., 0.90), 2. feature branches (that are potentially stale, i.e., HBASE-11288), 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). Can we decide it's okay to delete some of these? For (1), all of our release tags, going back to 0.1, are preserved. There's no benefit to keeping these. For (2), I think there's no discussion required, just someone to go check each Jira ID, and delete any that are closed, maybe with a comment on the Jira first. Maybe this could be automated? For (3), I suppose we need a case-by-case discussion? Maybe there are categories of these that can be resolved in blocks. Thanks, Nick
Re: Nightly builds are not running on branch-2.1
we have not yet had consensus to delete old branches. you will see we still have them going back quite a ways. please start a new DISCUSS thread if you want to pursue it. On Wed, May 20, 2020 at 2:39 PM Nick Dimiduk wrote: > Can we delete the old branch as well? > > On Wed, May 20, 2020 at 07:57 Sean Busbey wrote: > > > I updated the header. might take a bit for it to sync up. > > > > On Wed, May 20, 2020 at 9:55 AM Sean Busbey wrote: > > > > > hurm. looks like we missed some steps on cleaning up branch-2.1. the > EOL > > > isn't listed on our header for downloads.apache.org. > > > > > > we sent a notice to user@hbase in March when 2.1.10 was coming out: > > > https://s.apache.org/om9lb > > > > > > On Wed, May 20, 2020 at 3:28 AM ramkrishna vasudevan < > > > ramkrishna.s.vasude...@gmail.com> wrote: > > > > > >> Oh my bad. I did not realize that. Thanks for letting me know. > > >> > > >> On Wed, May 20, 2020, 1:54 PM Peter Somogyi > > wrote: > > >> > > >> > The branch-2.1 reached End of Life so the builds got disabled. The > > last > > >> > release from branch-2.1 is 2.1.10. > > >> > > > >> > On Wed, May 20, 2020 at 9:48 AM ramkrishna vasudevan < > > >> > ramkrishna.s.vasude...@gmail.com> wrote: > > >> > > > >> > > Hi All > > >> > > > > >> > > After we did some recent checkins for branch-2.1 and was waiting > for > > >> the > > >> > > nightly builds observed that the builds have not been running for > > >> last 10 > > >> > > days. > > >> > > > > >> > https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ > > >> > > > > >> > > Recently there was a compilation issue caused by HBASE-24186 > which > > I > > >> > > reverted couple of days ago. > > >> > > > > >> > > Is there a way we can trigger the nightly build once again? Or it > is > > >> some > > >> > > other known issue as in branch-2.2 (where a recent discussion had > > >> > > happened). > > >> > > > > >> > > Regards > > >> > > Ram > > >> > > > > >> > > > >> > > > > > > -- Sean
Re: Nightly builds are not running on branch-2.1
Can we delete the old branch as well? On Wed, May 20, 2020 at 07:57 Sean Busbey wrote: > I updated the header. might take a bit for it to sync up. > > On Wed, May 20, 2020 at 9:55 AM Sean Busbey wrote: > > > hurm. looks like we missed some steps on cleaning up branch-2.1. the EOL > > isn't listed on our header for downloads.apache.org. > > > > we sent a notice to user@hbase in March when 2.1.10 was coming out: > > https://s.apache.org/om9lb > > > > On Wed, May 20, 2020 at 3:28 AM ramkrishna vasudevan < > > ramkrishna.s.vasude...@gmail.com> wrote: > > > >> Oh my bad. I did not realize that. Thanks for letting me know. > >> > >> On Wed, May 20, 2020, 1:54 PM Peter Somogyi > wrote: > >> > >> > The branch-2.1 reached End of Life so the builds got disabled. The > last > >> > release from branch-2.1 is 2.1.10. > >> > > >> > On Wed, May 20, 2020 at 9:48 AM ramkrishna vasudevan < > >> > ramkrishna.s.vasude...@gmail.com> wrote: > >> > > >> > > Hi All > >> > > > >> > > After we did some recent checkins for branch-2.1 and was waiting for > >> the > >> > > nightly builds observed that the builds have not been running for > >> last 10 > >> > > days. > >> > > > >> https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ > >> > > > >> > > Recently there was a compilation issue caused by HBASE-24186 which > I > >> > > reverted couple of days ago. > >> > > > >> > > Is there a way we can trigger the nightly build once again? Or it is > >> some > >> > > other known issue as in branch-2.2 (where a recent discussion had > >> > > happened). > >> > > > >> > > Regards > >> > > Ram > >> > > > >> > > >> > > >
Re: Nightly builds are not running on branch-2.1
I updated the header. might take a bit for it to sync up. On Wed, May 20, 2020 at 9:55 AM Sean Busbey wrote: > hurm. looks like we missed some steps on cleaning up branch-2.1. the EOL > isn't listed on our header for downloads.apache.org. > > we sent a notice to user@hbase in March when 2.1.10 was coming out: > https://s.apache.org/om9lb > > On Wed, May 20, 2020 at 3:28 AM ramkrishna vasudevan < > ramkrishna.s.vasude...@gmail.com> wrote: > >> Oh my bad. I did not realize that. Thanks for letting me know. >> >> On Wed, May 20, 2020, 1:54 PM Peter Somogyi wrote: >> >> > The branch-2.1 reached End of Life so the builds got disabled. The last >> > release from branch-2.1 is 2.1.10. >> > >> > On Wed, May 20, 2020 at 9:48 AM ramkrishna vasudevan < >> > ramkrishna.s.vasude...@gmail.com> wrote: >> > >> > > Hi All >> > > >> > > After we did some recent checkins for branch-2.1 and was waiting for >> the >> > > nightly builds observed that the builds have not been running for >> last 10 >> > > days. >> > > >> https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ >> > > >> > > Recently there was a compilation issue caused by HBASE-24186 which I >> > > reverted couple of days ago. >> > > >> > > Is there a way we can trigger the nightly build once again? Or it is >> some >> > > other known issue as in branch-2.2 (where a recent discussion had >> > > happened). >> > > >> > > Regards >> > > Ram >> > > >> > >> >
[jira] [Resolved] (HBASE-24063) Make branch-2.1 EOM
[ https://issues.apache.org/jira/browse/HBASE-24063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-24063. - Resolution: Fixed > Make branch-2.1 EOM > --- > > Key: HBASE-24063 > URL: https://issues.apache.org/jira/browse/HBASE-24063 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24406) add EOM date for 2.1.x to downloads.a.o header
[ https://issues.apache.org/jira/browse/HBASE-24406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-24406. - Resolution: Fixed > add EOM date for 2.1.x to downloads.a.o header > -- > > Key: HBASE-24406 > URL: https://issues.apache.org/jira/browse/HBASE-24406 > Project: HBase > Issue Type: Sub-task >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (HBASE-24063) Make branch-2.1 EOM
[ https://issues.apache.org/jira/browse/HBASE-24063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reopened HBASE-24063: - > Make branch-2.1 EOM > --- > > Key: HBASE-24063 > URL: https://issues.apache.org/jira/browse/HBASE-24063 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24406) add EOM date for 2.1.x to downloads.a.o header
Sean Busbey created HBASE-24406: --- Summary: add EOM date for 2.1.x to downloads.a.o header Key: HBASE-24406 URL: https://issues.apache.org/jira/browse/HBASE-24406 Project: HBase Issue Type: Sub-task Reporter: Sean Busbey Assignee: Sean Busbey -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Nightly builds are not running on branch-2.1
hurm. looks like we missed some steps on cleaning up branch-2.1. the EOL isn't listed on our header for downloads.apache.org. we sent a notice to user@hbase in March when 2.1.10 was coming out: https://s.apache.org/om9lb On Wed, May 20, 2020 at 3:28 AM ramkrishna vasudevan < ramkrishna.s.vasude...@gmail.com> wrote: > Oh my bad. I did not realize that. Thanks for letting me know. > > On Wed, May 20, 2020, 1:54 PM Peter Somogyi wrote: > > > The branch-2.1 reached End of Life so the builds got disabled. The last > > release from branch-2.1 is 2.1.10. > > > > On Wed, May 20, 2020 at 9:48 AM ramkrishna vasudevan < > > ramkrishna.s.vasude...@gmail.com> wrote: > > > > > Hi All > > > > > > After we did some recent checkins for branch-2.1 and was waiting for > the > > > nightly builds observed that the builds have not been running for last > 10 > > > days. > > > > https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ > > > > > > Recently there was a compilation issue caused by HBASE-24186 which I > > > reverted couple of days ago. > > > > > > Is there a way we can trigger the nightly build once again? Or it is > some > > > other known issue as in branch-2.2 (where a recent discussion had > > > happened). > > > > > > Regards > > > Ram > > > > > >
Re: Docker command '/usr/bin/docker' is too old ( < 17.0).
The infra eam confirm that the machine is broken and offlined. It should be fine now. 张铎(Duo Zhang) 于2020年5月18日周一 上午11:55写道： > https://issues.apache.org/jira/browse/INFRA-20278 > > 张铎(Duo Zhang) 于2020年5月18日周一 上午11:52写道： > >> Checked the two jobs you provide, all the failed taska are on H10. >> >> Should be something wrong with this node. >> >> Let me file an infra issue. >> >> 张铎(Duo Zhang) 于2020年5月18日周一 上午11:30写道： >> >>> Checked this job. >>> >>> Seems H10 has the problem and H12 is fine. >>> >>> Guanghao Zhang 于2020年5月18日周一 上午10:45写道： >>> This error seems appeared since yesterday. Such as https://github.com/apache/hbase/pull/1727. And the nightly job meet same error. Such as https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/General_20Nightly_20Build_20Report/ What has been updated causing this problem? >>>
Re: Slack channel for hbase
Invitation sent. On Wed, May 20, 2020 at 1:17 PM Nand kishor Bansal wrote: > Hi, > > I would like to join slack channel for hbase. Can somebody please send me > an invite. > > Thanks, > Nand >
Slack channel for hbase
Hi, I would like to join slack channel for hbase. Can somebody please send me an invite. Thanks, Nand
[jira] [Resolved] (HBASE-24364) [Chaos Monkey] Invalid data block encoding in ChangeEncodingAction
[
https://issues.apache.org/jira/browse/HBASE-24364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-24364.
Resolution: Fixed
> [Chaos Monkey] Invalid data block encoding in ChangeEncodingAction
> --
>
> Key: HBASE-24364
> URL: https://issues.apache.org/jira/browse/HBASE-24364
> Project: HBase
> Issue Type: Bug
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.0, 2.2.5
>
>
> I found the following exception when I run ITBLL:
> {code:java}
> 2020-05-12 11:43:14,201 WARN [ChaosMonkey] policies.Policy: Exception
> performing action:
> java.lang.IllegalArgumentException: There is no data block encoder for given
> id '6'
> at
> org.apache.hadoop.hbase.io.encoding.DataBlockEncoding.getEncodingById(DataBlockEncoding.java:168)
> at
> org.apache.hadoop.hbase.chaos.actions.ChangeEncodingAction.lambda$perform$0(ChangeEncodingAction.java:50)
> at
> org.apache.hadoop.hbase.chaos.actions.Action.modifyAllTableColumns(Action.java:356)
> at
> org.apache.hadoop.hbase.chaos.actions.ChangeEncodingAction.perform(ChangeEncodingAction.java:48)
> at
> org.apache.hadoop.hbase.chaos.policies.PeriodicRandomActionPolicy.runOneIteration(PeriodicRandomActionPolicy.java:59)
> at
> org.apache.hadoop.hbase.chaos.policies.PeriodicPolicy.run(PeriodicPolicy.java:41)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Because PREFIX_TREE is removed in DataBlockEncoding:
> {code:java}
> /** Disable data block encoding. */
> NONE(0, null),
> // id 1 is reserved for the BITSET algorithm to be added later
> PREFIX(2, "org.apache.hadoop.hbase.io.encoding.PrefixKeyDeltaEncoder"),
> DIFF(3, "org.apache.hadoop.hbase.io.encoding.DiffKeyDeltaEncoder"),
> FAST_DIFF(4, "org.apache.hadoop.hbase.io.encoding.FastDiffDeltaEncoder"),
> // id 5 is reserved for the COPY_KEY algorithm for benchmarking
> // COPY_KEY(5, "org.apache.hadoop.hbase.io.encoding.CopyKeyDataBlockEncoder"),
> // PREFIX_TREE(6, "org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeCodec"),
> ROW_INDEX_V1(7, "org.apache.hadoop.hbase.io.encoding.RowIndexCodecV1");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-24405) Document hbase:slowlog in detail
Viraj Jasani created HBASE-24405: Summary: Document hbase:slowlog in detail Key: HBASE-24405 URL: https://issues.apache.org/jira/browse/HBASE-24405 Project: HBase Issue Type: Sub-task Reporter: Viraj Jasani Assignee: Viraj Jasani -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (HBASE-24364) [Chaos Monkey] Invalid data block encoding in ChangeEncodingAction
[
https://issues.apache.org/jira/browse/HBASE-24364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-24364:
[~meiyi] Need to push to branch-2, too.
> [Chaos Monkey] Invalid data block encoding in ChangeEncodingAction
> --
>
> Key: HBASE-24364
> URL: https://issues.apache.org/jira/browse/HBASE-24364
> Project: HBase
> Issue Type: Bug
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.0, 2.2.5
>
>
> I found the following exception when I run ITBLL:
> {code:java}
> 2020-05-12 11:43:14,201 WARN [ChaosMonkey] policies.Policy: Exception
> performing action:
> java.lang.IllegalArgumentException: There is no data block encoder for given
> id '6'
> at
> org.apache.hadoop.hbase.io.encoding.DataBlockEncoding.getEncodingById(DataBlockEncoding.java:168)
> at
> org.apache.hadoop.hbase.chaos.actions.ChangeEncodingAction.lambda$perform$0(ChangeEncodingAction.java:50)
> at
> org.apache.hadoop.hbase.chaos.actions.Action.modifyAllTableColumns(Action.java:356)
> at
> org.apache.hadoop.hbase.chaos.actions.ChangeEncodingAction.perform(ChangeEncodingAction.java:48)
> at
> org.apache.hadoop.hbase.chaos.policies.PeriodicRandomActionPolicy.runOneIteration(PeriodicRandomActionPolicy.java:59)
> at
> org.apache.hadoop.hbase.chaos.policies.PeriodicPolicy.run(PeriodicPolicy.java:41)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Because PREFIX_TREE is removed in DataBlockEncoding:
> {code:java}
> /** Disable data block encoding. */
> NONE(0, null),
> // id 1 is reserved for the BITSET algorithm to be added later
> PREFIX(2, "org.apache.hadoop.hbase.io.encoding.PrefixKeyDeltaEncoder"),
> DIFF(3, "org.apache.hadoop.hbase.io.encoding.DiffKeyDeltaEncoder"),
> FAST_DIFF(4, "org.apache.hadoop.hbase.io.encoding.FastDiffDeltaEncoder"),
> // id 5 is reserved for the COPY_KEY algorithm for benchmarking
> // COPY_KEY(5, "org.apache.hadoop.hbase.io.encoding.CopyKeyDataBlockEncoder"),
> // PREFIX_TREE(6, "org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeCodec"),
> ROW_INDEX_V1(7, "org.apache.hadoop.hbase.io.encoding.RowIndexCodecV1");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HBASE-24399) [Flakey Tests] Some UTs about RSGroup should wait RSGroupInfoManager to be online
[
https://issues.apache.org/jira/browse/HBASE-24399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-24399.
Resolution: Fixed
Pushed to branch-2.2, branch-2.3 and branch-2. Thanks [~Ddupg] for contributing.
> [Flakey Tests] Some UTs about RSGroup should wait RSGroupInfoManager to be
> online
> -
>
> Key: HBASE-24399
> URL: https://issues.apache.org/jira/browse/HBASE-24399
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.3.0
>Reporter: Sun Xin
>Assignee: Sun Xin
>Priority: Minor
> Fix For: 2.3.0, 2.2.5
>
>
> We will access table hbase:rsgroup when call addRSGroup, so we should ensure
> RSGroupInfoManagerImpl is online before testing in the UTs about RSGroup.
> Otherwise, the following exceptions may be saw.
> {code:java}
> java.io.IOException: java.io.IOException: Only servers in default group can
> be updated during offline modejava.io.IOException: java.io.IOException: Only
> servers in default group can be updated during offline mode at
> org.apache.hadoop.hbase.rsgroup.RSGroupInfoManagerImpl.flushConfig(RSGroupInfoManagerImpl.java:602)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupInfoManagerImpl.addRSGroup(RSGroupInfoManagerImpl.java:217)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.addRSGroup(RSGroupAdminServer.java:391)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Nightly builds are not running on branch-2.1
Oh my bad. I did not realize that. Thanks for letting me know. On Wed, May 20, 2020, 1:54 PM Peter Somogyi wrote: > The branch-2.1 reached End of Life so the builds got disabled. The last > release from branch-2.1 is 2.1.10. > > On Wed, May 20, 2020 at 9:48 AM ramkrishna vasudevan < > ramkrishna.s.vasude...@gmail.com> wrote: > > > Hi All > > > > After we did some recent checkins for branch-2.1 and was waiting for the > > nightly builds observed that the builds have not been running for last 10 > > days. > > https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ > > > > Recently there was a compilation issue caused by HBASE-24186 which I > > reverted couple of days ago. > > > > Is there a way we can trigger the nightly build once again? Or it is some > > other known issue as in branch-2.2 (where a recent discussion had > > happened). > > > > Regards > > Ram > > >
Re: Nightly builds are not running on branch-2.1
The branch-2.1 reached End of Life so the builds got disabled. The last release from branch-2.1 is 2.1.10. On Wed, May 20, 2020 at 9:48 AM ramkrishna vasudevan < ramkrishna.s.vasude...@gmail.com> wrote: > Hi All > > After we did some recent checkins for branch-2.1 and was waiting for the > nightly builds observed that the builds have not been running for last 10 > days. > https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ > > Recently there was a compilation issue caused by HBASE-24186 which I > reverted couple of days ago. > > Is there a way we can trigger the nightly build once again? Or it is some > other known issue as in branch-2.2 (where a recent discussion had > happened). > > Regards > Ram >
[jira] [Resolved] (HBASE-21996) Set locale for javadoc
[ https://issues.apache.org/jira/browse/HBASE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel resolved HBASE-21996. --- Resolution: Fixed Going to close this again, as our pushed Javadoc looks as expected. > Set locale for javadoc > -- > > Key: HBASE-21996 > URL: https://issues.apache.org/jira/browse/HBASE-21996 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Major > Fix For: 3.0.0-alpha-1, 2.3.0, 1.4.11, 1.3.6, 2.1.6, 2.2.1, 1.5.0 > > Attachments: HBASE-21996.master.001.patch, Screen Shot 2020-04-13 at > 5.09.36 PM.png, Screen Shot 2020-04-13 at 5.11.59 PM.png > > > Headers in generated javadoc could have different language based on the > user's locale. > For example the published 2.1 javadoc's headers are in Chinese while 2.0 is > in English. > 2.0: > [https://hbase.apache.org/2.0/apidocs/org/apache/hadoop/hbase/client/HTable.html] > 2.1: > [https://hbase.apache.org/2.1/apidocs/org/apache/hadoop/hbase/client/HTable.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
Nightly builds are not running on branch-2.1
Hi All After we did some recent checkins for branch-2.1 and was waiting for the nightly builds observed that the builds have not been running for last 10 days. https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/lastBuild/ Recently there was a compilation issue caused by HBASE-24186 which I reverted couple of days ago. Is there a way we can trigger the nightly build once again? Or it is some other known issue as in branch-2.2 (where a recent discussion had happened). Regards Ram
