Re: Time for 2.3.3

[ramkrishna vasudevan]

Hi Nick,
Apologies for the delayed reply.
If you see the current patch we are just ensuring that there is no
behaviour change by moving the archival to an async thread. So I don't
expect any behaviour change there. The existing behaviour was to abort the
server on an archival failure and now we are still doing it except the fact
that if needed user can configure a retry there. By default there is no
retry.
Yes the test related failures and in turn the changes required in the
postLogArchival has been taken care by Duo.
If you still feel it is too invasive then I will refrain from committing
the patch there. Thanks Nick.

Regards
Ram

On Wed, Oct 21, 2020 at 11:14 PM Nick Dimiduk  wrote:

> Hi Ram,
>
> Per my response on jira, I think this looks too invasive for a patch
> release, but I'm willing to be convinced otherwise. Looks like you and Duo
> were able to sort out the associated issue in HBASE-25186. Do you have a
> plan to test that extra WALs don't accumulate inadvertently?
>
> Thanks,
> Nick
>
> On Wed, Oct 21, 2020 at 9:57 AM ramkrishna vasudevan <
> ramkrishna.s.vasude...@gmail.com> wrote:
>
> > Hi Nick
> >
> > Can I port https://issues.apache.org/jira/browse/HBASE-25065 to
> branch-2.2
> > - Note that it is an improvement?
> >
> > Regards
> > Ram
> >
> > On Wed, Oct 21, 2020 at 10:05 PM Nick Dimiduk 
> wrote:
> >
> > > Hello team,
> > >
> > > It's come around to that time again. We have about 30 improvements on
> the
> > > branch, which is my litmus test for another patch release. Please try
> to
> > > land any patches you have in flight, and plan for an RC on or around
> > > Tuesday, 27 Oct.
> > >
> > > Thanks,
> > > Nick
> > >
> >
>

[jira] [Resolved] (HBASE-25128) RSGroupInfo's toString() and hashCode() does not take into account configuration map.

[Guanghao Zhang (Jira)]

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

Guanghao Zhang resolved HBASE-25128.

Fix Version/s: 2.4.0
   3.0.0-alpha-1
   Resolution: Fixed

Pushed to branch-2 and master. Thanks [~sanjeetnishad] for contributing.

> RSGroupInfo's toString() and hashCode() does not take into account 
> configuration map.
> -
>
> Key: HBASE-25128
> URL: https://issues.apache.org/jira/browse/HBASE-25128
> Project: HBase
>  Issue Type: Improvement
>  Components: rsgroup
>Affects Versions: 2.2.3
>Reporter: Sanjeet Nishad
>Assignee: Sanjeet Nishad
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.4.0
>
>
> RSGroupInfo's toString() and hashcode() methods should include Configurations 
> as well which is added as a part of HBASE-24431.



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

[jira] [Resolved] (HBASE-25214) about hbase introduced fasterxml‘s jackson versions and vulnerabilities

[Sean Busbey (Jira)]

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

Sean Busbey resolved HBASE-25214.
-
Resolution: Duplicate

This is a duplicate of HBASE-24802. Please follow our work over there. Help in 
testing out the solution would be appreciated.

> about hbase introduced fasterxml‘s jackson versions and vulnerabilities 
> 
>
> Key: HBASE-25214
> URL: https://issues.apache.org/jira/browse/HBASE-25214
> Project: HBase
>  Issue Type: Improvement
>Reporter: openlookeng
>Priority: Blocker
>
> a lot of hbase component use htrace-core4, this htrace-core4 shaded fasterxml 
> jackson(version 2.4.0)
> [INFO] | +- 
> org.apache.hbase.thirdparty:hbase-shaded-miscellaneous:jar:2.2.1:compile
>  [INFO] | +- org.slf4j:slf4j-api:jar:1.7.29:compile
>  [INFO] | +- commons-io:commons-io:jar:2.6:compile
>  [INFO] | +- 
> {color:#ff}org.apache.htrace:htrace-core4:jar:4.2.0-incubating:compile{color}
>  [INFO] | +- org.apache.commons:commons-crypto:jar:1.0.0:compile
>  [INFO] | +- 
> com.github.stephenc.findbugs:findbugs-annotations:jar:1.3.9-1:compile
>  [INFO] | +- log4j:log4j:jar:1.2.17:compile
>  [INFO] | - org.apache.yetus:audience-annotations:jar:0.5.0:compile
>  
> as you known fasterxml  jackson component is frequently coming out new 
> vulnerabilities, like   
> CVE-2016-7051、CVE-2016-3720、CVE-2018-5968、CVE-2018-11307、CVE-2018-7489、CVE-2019-14893、CVE-2019-14379、CVE-2020-14195、CVE-2020-14061、CVE-2020-8840、CVE-2019-14540、CVE-2020-10968、CVE-2020-11619、CVE-2019-17531、CVE-2019-16943、CVE-2020-14062、CVE-2020-14060、CVE-2020-1、CVE-2019-16942、CVE-2020-9546、CVE-2020-9548、CVE-2019-12384、CVE-2020-10673、CVE-2020-24750、CVE-2019-16335、CVE-2019-14439、CVE-2020-10969、CVE-2020-2、CVE-2019-12086、CVE-2019-20330、CVE-2019-17267、CVE-2020-9547、CVE-2020-3、CVE-2020-10672、CVE-2020-11620、CVE-2020-24616、CVE-2018-19362、CVE-2018-19361、CVE-2018-19360、CVE-2018-14721、CVE-2018-14720、CVE-2018-14719、CVE-2018-14718、CVE-2018-1000873、CVE-2017-7525、CVE-2017-17485、CVE-2017-15095，CVE-2019-12814
> htrace-core4 is closed 4 years ago,  what about this component's 
> vulnerabilities, did hbase have plan to do with this？
>  
>  
>  



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

Re: [DISCUSS] the IA annotation on hbase client exceptions

[Sean Busbey]

Why are we not just leaving things IA.Private? What are we trying to
enable? Don't downstream clients just need DoNotRetryIOException and
IOException?

If we're going to go with LimitedPrivate is it worth defining a LP
audience that means "you can refer safely to this class name but you
should not instantiate or extend the class and you should not call any
methods on it"? something like LimitedPrivate(OPAQUE) and then we
could also use that to annotate classes that are not IA.Public but
appear in IA.Public method signatures?

Maybe something like EXCEPTION_HANDLING would be clearer though. The
existing LP audience of CONFIG is kind of like that, where we say the
fully qualified classname needs special handling because it could
appear in configuration files.

On Thu, Oct 22, 2020 at 1:42 AM 张铎(Duo Zhang)  wrote:
>
> Let's wait for a while to see if there are other feedbacks.
>
> Yulin Niu  于2020年10月21日周三 上午11:58写道：
>
> > So, we introduce a new Annotation IA.LimitedPrivate(Exception) to decorate
> > the exceptions, which are free to catched and propagated by users, but
> > should not be created by users themselves.
> >
> > 张铎(Duo Zhang)  于2020年10月18日周日 下午10:08写道：
> >
> > > I think IA.Public maybe over killed here for some exceptions.
> > > For example, the DoNotRetryIOException, we just want users to catch this
> > > exception, but usually we do not expect users to create this exeption by
> > > their own?
> > > But IA.Public means we can not change the public methods of the class, so
> > > we can not even remove constructors of the exception?
> > >
> > > Maybe special IA.LimitedPrivate(Exception)? Which means you are free to
> > > catch and propagate the exception, but you should not create it by
> > > yourselves? Or use the special methods of the exception?
> > >
> > > Sean Busbey  于2020年10月18日周日 下午9:46写道：
> > >
> > > > My guess would be IA.Public is needed if the client can take action
> > based
> > > > on the specific exception. So like the do not retry exception should be
> > > > public so folks know those IOExceptions that it's not worth baking off
> > > and
> > > > retrying.
> > > >
> > > > What's the specific list of public vs not? Why do you want the non
> > public
> > > > ones to be public? What limitations are we putting on clients by
> > keeping
> > > > them private?
> > > >
> > > > On Sun, Oct 18, 2020, 07:45 Yulin Niu 
> > wrote:
> > > >
> > > > > Hi, guys:
> > > > >
> > > > > There are IA.Public and also IA.Private under the hbase-client
> > > > exceptions
> > > > > package, whether the IA.Private exceptions should be IA.Public?
> > > > > e.g.MasterRegistryFetchException, OutOfOrderScannerNextException
> > > > > ,RegionMovedException,RegionOpeningException
> > > > > And any others thing about the IA annotation on exceptions?
> > > > > FYI 2538 
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > >
> >



-- 
Sean

[jira] [Resolved] (HBASE-25207) Revisit the implementation and usage of RegionStates.include

[Duo Zhang (Jira)]

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

Duo Zhang resolved HBASE-25207.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Pushed to branch-2.2+.

Thanks [~brfrn169] for reviewing.

> Revisit the implementation and usage of RegionStates.include
> 
>
> Key: HBASE-25207
> URL: https://issues.apache.org/jira/browse/HBASE-25207
> Project: HBase
>  Issue Type: Bug
>  Components: Region Assignment
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.7
>
>
> After several round of refactoring and fixing, the method has been used in 
> lots of places and the implementation looks really confusing.
> As in the first if condition for testing RegionStateNode and RegionInfo 
> state, we will always return false when split is true, which means we will 
> always filter out split parent, as a split parent, is split = true and also 
> offline = true.
> I think the reason why there is no problem is that, only in 
> EnableTableProcedure we call this method with offline = true, and 
> EnableTableProcedure does not need to deal with split parent...
> And now since we found a problem in HBASE-25206, where we need to get split 
> parent when deleting a table, I think it is time to revisit this method and 
> make logic less confusing.



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

[jira] [Created] (HBASE-25214) HTrace is not maintained. Please fix these vulnerabilities?

[openlookeng (Jira)]

openlookeng created HBASE-25214:
---

 Summary: HTrace is not maintained. Please fix these 
vulnerabilities?
 Key: HBASE-25214
 URL: https://issues.apache.org/jira/browse/HBASE-25214
 Project: HBase
  Issue Type: Improvement
Reporter: openlookeng


Jackson has been updated for the Apache HBase REST Proxy to address  
CVE-2016-7051、CVE-2016-3720、CVE-2018-5968、CVE-2018-11307、CVE-2018-7489、CVE-2019-14893、CVE-2019-14379、CVE-2020-14195、CVE-2020-14061、CVE-2020-8840、CVE-2019-14540、CVE-2020-10968、CVE-2020-11619、CVE-2019-17531、CVE-2019-16943、CVE-2020-14062、CVE-2020-14060、CVE-2020-1、CVE-2019-16942、CVE-2020-9546、CVE-2020-9548、CVE-2019-12384、CVE-2020-10673、CVE-2020-24750、CVE-2019-16335、CVE-2019-14439、CVE-2020-10969、CVE-2020-2、CVE-2019-12086、CVE-2019-20330、CVE-2019-17267、CVE-2020-9547、CVE-2020-3、CVE-2020-10672、CVE-2020-11620、CVE-2020-24616、CVE-2018-19362、CVE-2018-19361、CVE-2018-19360、CVE-2018-14721、CVE-2018-14720、CVE-2018-14719、CVE-2018-14718、CVE-2018-1000873、CVE-2017-7525、CVE-2017-17485、CVE-2017-15095



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

[jira] [Created] (HBASE-25213) Should request Compaction after bulkLoadHFiles is done

[niuyulin (Jira)]

niuyulin created HBASE-25213:


 Summary: Should request Compaction after bulkLoadHFiles is done
 Key: HBASE-25213
 URL: https://issues.apache.org/jira/browse/HBASE-25213
 Project: HBase
  Issue Type: Improvement
Reporter: niuyulin
Assignee: niuyulin






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