[jira] [Created] (HBASE-28632) Make -h arg respected by

[Sravi Kommineni (Jira)]

Sravi Kommineni created HBASE-28632:
---

 Summary: Make -h arg respected by 
 Key: HBASE-28632
 URL: https://issues.apache.org/jira/browse/HBASE-28632
 Project: HBase
  Issue Type: Bug
Reporter: Sravi Kommineni


The -h argument in hbck is not respected and instead of displaying the argument 
usage guide, the command continued to execute. Any unrecognized arguments 
should cause an exception and exit.

 

example: 
{code:java}
$ hbck2 addFsRegionsMissingInMeta -h
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; 
support was removed in 17.0
19:09:08.831 [main] INFO  org.apache.hadoop.conf.Configuration.deprecation - 
hbase.client.pause.cqtbe is deprecated. Instead, use 
hbase.client.pause.server.overloaded
ERROR: Unrecognized option: -h
FOR USAGE, use the -h or --help option {code}
 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-28546) Make WAL rolling exception clear

[Wei-Chiu Chuang (Jira)]

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

Wei-Chiu Chuang resolved HBASE-28546.
-
Resolution: Fixed

> Make WAL rolling exception clear
> 
>
> Key: HBASE-28546
> URL: https://issues.apache.org/jira/browse/HBASE-28546
> Project: HBase
>  Issue Type: Bug
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.0.0-alpha-1, 3.0.0-beta-2, 2.6.1, 2.5.9
>
>
> Occasionally we see errors like this that doesn't really give much clue what 
> went wrong.
> {noformat}
> 2024-04-22 08:08:02,026 ERROR org.apache.hadoop.hbase.master.HMaster: * 
> ABORTING master ccycloud-7.ozn-hb973chf3oz.xyz,22001,1713770648404: Log 
> rolling failed *
> java.lang.RuntimeException
> at 
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.writeWALMetadata(AsyncProtobufLogWriter.java:217)
> at 
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.writeMagicAndWALHeader(AsyncProtobufLogWriter.java:223)
> at 
> org.apache.hadoop.hbase.regionserver.wal.AbstractProtobufLogWriter.init(AbstractProtobufLogWriter.java:164)
> at 
> org.apache.hadoop.hbase.wal.AsyncFSWALProvider.createAsyncWriter(AsyncFSWALProvider.java:116)
> at 
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.createWriterInstance(AsyncFSWAL.java:726)
> at 
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.createWriterInstance(AsyncFSWAL.java:129)
> at 
> org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.rollWriter(AbstractFSWAL.java:886)
> at 
> org.apache.hadoop.hbase.wal.AbstractWALRoller$RollController.rollWal(AbstractWALRoller.java:304)
> at 
> org.apache.hadoop.hbase.wal.AbstractWALRoller.run(AbstractWALRoller.java:211)
> {noformat}
> In this case, it was due to a time out exception. It would be helpful to make 
> the log message more friendly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Failure: HBase Generate Website

[Apache Jenkins Server]

Build status: FAILURE

The HBase website has not been updated to incorporate recent HBase changes.

See https://ci-hbase.apache.org/job/hbase_generate_website/540/console

Re: [DISCUSS] Marking Filters based on their hinting / row stateful behaviours.

[Istvan Toth]

It turns out that ColumnPaginationFilter is both row stateful and can
return a seek hint.
I have removed the HintingFilter marker from it to preserve the correct
operation.

With this change, ColumnPaginationFilter is no worse off than it was, but
the rest of the hinting
filters will work correctly.

On Fri, May 31, 2024 at 9:32 AM Istvan Toth  wrote:

> This is indeed quite a small change.
> The PR is up at https://github.com/apache/hbase/pull/5955
>
> On Wed, May 29, 2024 at 10:07 AM Istvan Toth  wrote:
>
>> Thanks for the detailed reply, Andrew.
>>
>> I was also considering default methods, but it turns out that Filter is
>> not an interface, but an abstract class, so it doesn't apply.
>>
>> Children not implementing a marker interface or marker method would
>> inherit the marker method implementation from the closest parent the same
>> way they would inherit the marker interface, so I think they are equivalent
>> in this aspect, too.
>>
>> I think that marker interface(s) and overridable non-abstract getter(s)
>> in Filter are mostly equivalent from both logical and source compatibility
>> aspects.
>> The only difference is that the marker interfaces cannot be removed in a
>> subclass, while the getter can be overridden anywhere, but with well-chosen
>> defaults it shouldn't be much of a limitation.
>>
>> Now that I think about it, we could cache the markers' values in an array
>> when creating the filter lists, so even the cost of looking them up doesn't
>> matter as it wouldn't happen in the hot code path.
>>
>> Using the marker interfaces is more elegant, and discourages problematic
>> subclassing, so I am leaning towards that.
>>
>> Istvan
>>
>> On Wed, May 29, 2024 at 2:30 AM Andrew Purtell 
>> wrote:
>>
>>> Actually source compatibility with default methods would be fine too. I
>>> forget this is the main reason default methods were invented. The code of
>>> derived classes would not need to be changed, unless the returned value
>>> of
>>> the new method should be changed, and this is no worse than having a
>>> marker
>>> interface, which would also require code changes to implement non-default
>>> behaviors.
>>>
>>> A marker interface does remain as an option. It might make a difference
>>> in
>>> chained use cases. Consider a chain of filter instances that mixes
>>> derived
>>> code that is unaware of isHinting() and base code that is. The filter
>>> chain
>>> can be examined for the presence or absence of the marker interface and
>>> would not need to rely on every filter in the chain passing return values
>>> of isHinting back.
>>>
>>> Marker interfaces can also be added to denote stateful or stateless
>>> filters, if distinguishing between them would be useful, perhaps down the
>>> road.
>>>
>>> On Tue, May 28, 2024 at 5:13 PM Andrew Purtell 
>>> wrote:
>>>
>>> > I think you've clearly put a lot of time into the analysis and it is
>>> > plausible.
>>> >
>>> > Adding isHinting as a default method will preserve binary
>>> compatibility.
>>> > Source compatibility for derived custom filters would be broken though
>>> and
>>> > that probably prevents this going back into a releasing code line.
>>> >
>>> > Have you considered adding a marker interface instead? That would
>>> preserve
>>> > both source and binary compatibility. It wouldn't require any changes
>>> to
>>> > derived custom filters. A runtime instanceof test would determine if
>>> the
>>> > filter is a hinting filter or not. No need for a new method, default or
>>> > otherwise.
>>> >
>>> > On Tue, May 28, 2024 at 12:41 AM Istvan Toth  wrote:
>>> >
>>> >> I have recently opened HBASE-28622
>>> >>  , which has
>>> turned
>>> >> out
>>> >> to be another aspect of the problem discussed in HBASE-20565
>>> >>  .
>>> >>
>>> >> The problem is discussed in detail in HBASE-20565
>>> >>  , but it boils
>>> down
>>> >> to
>>> >> the API design decision that the filters returning
>>> SEEK_NEXT_USING_HINT
>>> >> rely on filterCell() getting called.
>>> >>
>>> >> On the other hand, some filters maintain an internal row state that
>>> sets
>>> >> counters for calls of filterCell(), which interacts with the results
>>> of
>>> >> previous filters in a filterList.
>>> >>
>>> >> When filters return different results for filterRowkey(), then filters
>>> >> returning  SEEK_NEXT_USING_HINT that have returned false must have
>>> >> filterCell() called, otherwise the scan will degenerate into a full
>>> scan.
>>> >>
>>> >> On the other hand, filters that maintain an internal row state must
>>> only
>>> >> be
>>> >> called if all previous filters have INCLUDEed the Cell, otherwise
>>> their
>>> >> internal state will be off. (This still has caveats, as described in
>>> >> HBASE-20565 )
>>> >>
>>> >> In my opinion, the current code from HBASE-20565
>>> >> 

Re: [ANNOUNCE] New HBase committer Andor Molnár

[Andor Molnar]

Thank y'all!


On Wed, 2024-05-29 at 17:13 -0400, Bryan Beaudreault wrote:
> Congrats and welcome!
> 
> On Wed, May 29, 2024 at 5:06 PM Viraj Jasani 
> wrote:
> 
> > Congratulations and Welcome, Andor! Well deserved!!
> > 
> > 
> > On Wed, May 29, 2024 at 7:36 AM Duo Zhang 
> > wrote:
> > 
> > > On behalf of the Apache HBase PMC, I am pleased to announce that
> > > Andor Molnár(andor) has accepted the PMC's invitation to become a
> > > committer on the project. We appreciate all of Andor Molnár's
> > > generous contributions thus far and look forward to his continued
> > > involvement.
> > > 
> > > Congratulations and welcome, Andor Molnár!
> > > 
> > > 我很高兴代表 Apache HBase PMC 宣布 Andor Molnár 已接受我们的邀请，成
> > > 为 Apache HBase 项目的 Committer。感谢 Andor Molnár 一直以来为 HBase 项目
> > > 做出的贡献，并期待他在未来继续承担更多的责任。
> > > 
> > > 欢迎 Andor Molnár！
> > > 

Re: [DISCUSS] Marking Filters based on their hinting / row stateful behaviours.

[Istvan Toth]

This is indeed quite a small change.
The PR is up at https://github.com/apache/hbase/pull/5955

On Wed, May 29, 2024 at 10:07 AM Istvan Toth  wrote:

> Thanks for the detailed reply, Andrew.
>
> I was also considering default methods, but it turns out that Filter is
> not an interface, but an abstract class, so it doesn't apply.
>
> Children not implementing a marker interface or marker method would
> inherit the marker method implementation from the closest parent the same
> way they would inherit the marker interface, so I think they are equivalent
> in this aspect, too.
>
> I think that marker interface(s) and overridable non-abstract getter(s) in
> Filter are mostly equivalent from both logical and source compatibility
> aspects.
> The only difference is that the marker interfaces cannot be removed in a
> subclass, while the getter can be overridden anywhere, but with well-chosen
> defaults it shouldn't be much of a limitation.
>
> Now that I think about it, we could cache the markers' values in an array
> when creating the filter lists, so even the cost of looking them up doesn't
> matter as it wouldn't happen in the hot code path.
>
> Using the marker interfaces is more elegant, and discourages problematic
> subclassing, so I am leaning towards that.
>
> Istvan
>
> On Wed, May 29, 2024 at 2:30 AM Andrew Purtell 
> wrote:
>
>> Actually source compatibility with default methods would be fine too. I
>> forget this is the main reason default methods were invented. The code of
>> derived classes would not need to be changed, unless the returned value of
>> the new method should be changed, and this is no worse than having a
>> marker
>> interface, which would also require code changes to implement non-default
>> behaviors.
>>
>> A marker interface does remain as an option. It might make a difference in
>> chained use cases. Consider a chain of filter instances that mixes derived
>> code that is unaware of isHinting() and base code that is. The filter
>> chain
>> can be examined for the presence or absence of the marker interface and
>> would not need to rely on every filter in the chain passing return values
>> of isHinting back.
>>
>> Marker interfaces can also be added to denote stateful or stateless
>> filters, if distinguishing between them would be useful, perhaps down the
>> road.
>>
>> On Tue, May 28, 2024 at 5:13 PM Andrew Purtell 
>> wrote:
>>
>> > I think you've clearly put a lot of time into the analysis and it is
>> > plausible.
>> >
>> > Adding isHinting as a default method will preserve binary compatibility.
>> > Source compatibility for derived custom filters would be broken though
>> and
>> > that probably prevents this going back into a releasing code line.
>> >
>> > Have you considered adding a marker interface instead? That would
>> preserve
>> > both source and binary compatibility. It wouldn't require any changes to
>> > derived custom filters. A runtime instanceof test would determine if the
>> > filter is a hinting filter or not. No need for a new method, default or
>> > otherwise.
>> >
>> > On Tue, May 28, 2024 at 12:41 AM Istvan Toth  wrote:
>> >
>> >> I have recently opened HBASE-28622
>> >>  , which has turned
>> >> out
>> >> to be another aspect of the problem discussed in HBASE-20565
>> >>  .
>> >>
>> >> The problem is discussed in detail in HBASE-20565
>> >>  , but it boils
>> down
>> >> to
>> >> the API design decision that the filters returning SEEK_NEXT_USING_HINT
>> >> rely on filterCell() getting called.
>> >>
>> >> On the other hand, some filters maintain an internal row state that
>> sets
>> >> counters for calls of filterCell(), which interacts with the results of
>> >> previous filters in a filterList.
>> >>
>> >> When filters return different results for filterRowkey(), then filters
>> >> returning  SEEK_NEXT_USING_HINT that have returned false must have
>> >> filterCell() called, otherwise the scan will degenerate into a full
>> scan.
>> >>
>> >> On the other hand, filters that maintain an internal row state must
>> only
>> >> be
>> >> called if all previous filters have INCLUDEed the Cell, otherwise their
>> >> internal state will be off. (This still has caveats, as described in
>> >> HBASE-20565 )
>> >>
>> >> In my opinion, the current code from HBASE-20565
>> >>  strikes a bad
>> balance
>> >> between features, as while it fixes some use cases for row stateful
>> >> filters, it also often negates the performance benefits of the filters
>> >> providing hints, which in practice makes them unusable in many filter
>> list
>> >> combinations.
>> >>
>> >> Without completely re-designing the filter system, I think that the
>> best
>> >> solution would be adding a method to distinguish the filters that can
>> >> return