[jira] [Created] (HBASE-26868) Introduce read/write request size metrics

[Xiaolin Ha (Jira)]

Xiaolin Ha created HBASE-26868:
--

 Summary: Introduce read/write request size metrics
 Key: HBASE-26868
 URL: https://issues.apache.org/jira/browse/HBASE-26868
 Project: HBase
  Issue Type: Sub-task
  Components: regionserver
Affects Versions: 2.4.11
Reporter: Xiaolin Ha
Assignee: Xiaolin Ha
 Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3


Calculating the read and write size(unit is bytes) in the region, and 
aggregated in table and regionserver levels.



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

[jira] [Created] (HBASE-26867) Introduce a FlushProcedure

[ruanhui (Jira)]

ruanhui created HBASE-26867:
---

 Summary: Introduce a FlushProcedure
 Key: HBASE-26867
 URL: https://issues.apache.org/jira/browse/HBASE-26867
 Project: HBase
  Issue Type: New Feature
  Components: proc-v2
Reporter: ruanhui
Assignee: ruanhui
 Fix For: 2.6.0, 3.0.0-alpha-3


Reimplement proc-v1 based flush procedure in proc-v2.



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

[ANNOUNCE] Apache HBase 2.4.11 is now available for download

[Andrew Purtell]

The HBase team is happy to announce the immediate availability of HBase
2.4.11.

Apache HBase™ is an open-source, distributed, versioned, non-relational
database.

Apache HBase gives you low latency random access to billions of rows with
millions of columns atop non-specialized hardware. To learn more about
HBase, see https://hbase.apache.org/.

HBase 2.4.11 is the eleventh patch release in the HBase 2.4.x line. The
full list of issues can be found in the included CHANGES and RELEASENOTES,
or via our issue tracker:

https://s.apache.org/hbase-2.4.11-jira

To download please follow the links and instructions on our website:

https://hbase.apache.org/downloads.html

Questions, comments, and problems are always welcome at:
dev@hbase.apache.org.

Thanks to all who contributed and made this release possible.

Cheers,
The HBase Dev Team

Re: [DISCUSS] EOM 1.7 and branch-1? (proposal: 2022/07/21)

[Andrew Purtell]

Sure. It’s fine to ask.

The issue is lack of interest and resources for releasing, primarily. If 
someone steps up to RM the code line and can produce releases on a regular 
basis - and we need to see it happen, not simply accept a promise - then EOM 
would be premature.

As things stand Reid made two (1.7.0 and 1.7.1) and then went away. Since then 
the branch has not been maintained by a coordinating actor and that makes the 
current state unclear.  Perhaps due to the lack of attention it may still be 
stable, but it is in need of more considered and active maintenance. Otherwise, 
it should be EOMed, in my opinion.


> On Mar 19, 2022, at 7:03 AM, Sean Busbey  wrote:
> 
> I think it’d be worth checking with user@ to see if there are continued
> users of branch-1 that would be interested in getting more involved to keep
> the branch going with eg dependency updates and security fixes should they
> be needed.
> 
> 
> 
>> On Fri, Mar 18, 2022 at 11:43 PM Viraj Jasani  wrote:
>> 
>> +1 for the EOM of branch-1. We occasionally commit few minor fixes if
>> required, beyond that it doesn’t get much attention.
>> Perhaps no need to wait for one year anniversary of 1.7 release if we have
>> sufficient votes to retire branch-1 sooner?
>> 
>> 
>> On Fri, 18 Mar 2022 at 3:06 AM, Andrew Purtell 
>> wrote:
>> 
>>> We previously discussed this topic on this thread:
>>> 
>>>  https://lists.apache.org/thread/hlp18jjjxxpf62spd8zkhmht23hmpljg
>>> 
>>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>>> 
>>> There doesn't seem to be much developer interest in branch-1 beyond
>>> occasional maintenance. This is understandable. Per our compatibility
>>> guidelines, branch-1 commits must be compatible with Java 7, and the
>> range
>>> of acceptable versions of third party dependencies is also restricted due
>>> to Java 7 compatibility requirements. Most developers are writing code
>> with
>>> Java 8+ idioms these days. For that reason and because the branch-1 code
>>> base is generally aged at this point, all but trivial (or lucky!)
>> backports
>>> require substantial changes in order to integrate adequately. Let me also
>>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>>> later.
>>> 
>>> It is my more recent observation that relatively little maintenance
>>> activity is occurring with respect to branch-1.
>>> 
>>> The last release from branch-1 was 1.7.1, on 2021/07/21.
>>> 
>>> If there are no more 1.x releases in the meantime, shall we use the
>>> occasion of the one year anniversary of this last 1.x release and
>> announce
>>> EOM of HBase 1.7 and all of branch-1 on or about 2022/07/21 ?
>>> 
>>> --
>>> Best regards,
>>> Andrew
>>> 
>> 

Re: [DISCUSS] EOM 1.7 and branch-1? (proposal: 2022/07/21)

[Sean Busbey]

Sorry for the lack of clarity. I meant to include that I’ll send the
message to the user list later today if folks don’t have a specific concern
with me doing so.

On Sat, Mar 19, 2022 at 9:03 AM Sean Busbey  wrote:

> I think it’d be worth checking with user@ to see if there are continued
> users of branch-1 that would be interested in getting more involved to keep
> the branch going with eg dependency updates and security fixes should they
> be needed.
>
>
>
> On Fri, Mar 18, 2022 at 11:43 PM Viraj Jasani  wrote:
>
>> +1 for the EOM of branch-1. We occasionally commit few minor fixes if
>> required, beyond that it doesn’t get much attention.
>> Perhaps no need to wait for one year anniversary of 1.7 release if we have
>> sufficient votes to retire branch-1 sooner?
>>
>>
>> On Fri, 18 Mar 2022 at 3:06 AM, Andrew Purtell 
>> wrote:
>>
>> > We previously discussed this topic on this thread:
>> >
>> >   https://lists.apache.org/thread/hlp18jjjxxpf62spd8zkhmht23hmpljg
>> >
>> > Is it time to consider EOL of branch-1 and all 1.x releases ?
>> >
>> > There doesn't seem to be much developer interest in branch-1 beyond
>> > occasional maintenance. This is understandable. Per our compatibility
>> > guidelines, branch-1 commits must be compatible with Java 7, and the
>> range
>> > of acceptable versions of third party dependencies is also restricted
>> due
>> > to Java 7 compatibility requirements. Most developers are writing code
>> with
>> > Java 8+ idioms these days. For that reason and because the branch-1 code
>> > base is generally aged at this point, all but trivial (or lucky!)
>> backports
>> > require substantial changes in order to integrate adequately. Let me
>> also
>> > observe that branch-1 artifacts are not fully compatible with Java 11 or
>> > later.
>> >
>> > It is my more recent observation that relatively little maintenance
>> > activity is occurring with respect to branch-1.
>> >
>> > The last release from branch-1 was 1.7.1, on 2021/07/21.
>> >
>> > If there are no more 1.x releases in the meantime, shall we use the
>> > occasion of the one year anniversary of this last 1.x release and
>> announce
>> > EOM of HBase 1.7 and all of branch-1 on or about 2022/07/21 ?
>> >
>> > --
>> > Best regards,
>> > Andrew
>> >
>>
>

Re: [DISCUSS] EOM 1.7 and branch-1? (proposal: 2022/07/21)

[Sean Busbey]

I think it’d be worth checking with user@ to see if there are continued
users of branch-1 that would be interested in getting more involved to keep
the branch going with eg dependency updates and security fixes should they
be needed.



On Fri, Mar 18, 2022 at 11:43 PM Viraj Jasani  wrote:

> +1 for the EOM of branch-1. We occasionally commit few minor fixes if
> required, beyond that it doesn’t get much attention.
> Perhaps no need to wait for one year anniversary of 1.7 release if we have
> sufficient votes to retire branch-1 sooner?
>
>
> On Fri, 18 Mar 2022 at 3:06 AM, Andrew Purtell 
> wrote:
>
> > We previously discussed this topic on this thread:
> >
> >   https://lists.apache.org/thread/hlp18jjjxxpf62spd8zkhmht23hmpljg
> >
> > Is it time to consider EOL of branch-1 and all 1.x releases ?
> >
> > There doesn't seem to be much developer interest in branch-1 beyond
> > occasional maintenance. This is understandable. Per our compatibility
> > guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> > of acceptable versions of third party dependencies is also restricted due
> > to Java 7 compatibility requirements. Most developers are writing code
> with
> > Java 8+ idioms these days. For that reason and because the branch-1 code
> > base is generally aged at this point, all but trivial (or lucky!)
> backports
> > require substantial changes in order to integrate adequately. Let me also
> > observe that branch-1 artifacts are not fully compatible with Java 11 or
> > later.
> >
> > It is my more recent observation that relatively little maintenance
> > activity is occurring with respect to branch-1.
> >
> > The last release from branch-1 was 1.7.1, on 2021/07/21.
> >
> > If there are no more 1.x releases in the meantime, shall we use the
> > occasion of the one year anniversary of this last 1.x release and
> announce
> > EOM of HBase 1.7 and all of branch-1 on or about 2022/07/21 ?
> >
> > --
> > Best regards,
> > Andrew
> >
>

Posting EOM to user-zh

[Sean Busbey]

Could someone translate the 2.3 EOM notice for the user-zh mailing list?

Longer term we should track a template that can get filled in for each of
the user lists so the poster needn’t be particularly proficient in either
language.

[jira] [Reopened] (HBASE-26813) Remove javax.ws.rs-api dependency

[Duo Zhang (Jira)]

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

Duo Zhang reopened HBASE-26813:
---

This breaks some tests. Maybe we still need to add it when running UTs.

> Remove javax.ws.rs-api dependency
> -
>
> Key: HBASE-26813
> URL: https://issues.apache.org/jira/browse/HBASE-26813
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.5.0, 2.6.0, 3.0.0-alpha-3
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
> Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3
>
>
> I see that we still have {{javax.ws.rs-api}} as a dependency in our 
> hbase-http pom. If, for example, the {{ClientBuilder}} from this jar is used, 
> it'll instantiate whatever non-shaded jersey client is on the class path.



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

[NOTICE] Compatibility issue between Replication and WAL Compression

[唐天航]

At present, there is a compatibility problem if Replication and WAL
Compression are used together. It might cause the WAL queue of replication
to overstock.
Branch-1, branch-2, master all be affected.
See details in HBASE-26849
.

We already have a fix plan. But before the patch is ready, if you need to
use Replication, it is highly recommended to *make sure that WAL
Compression is turned off.*