Re: HBase 0.94.15: writes stalls periodically even under moderate steady load (AWS EC2)

This might be better on the user list? Anyway.. How many IPC handlers are you giving? m1.xlarge is very low cpu. Not only does it have only 4 cores (more cores allow more concurrent threads with less context switching), but those cores are severely underpowered. I would recommend at least

Re: Leaving the world of SQL, need some basic guidance and/or ideas

Coprocessors: https://blogs.apache.org/hbase/entry/coprocessor_introduction The blog appears to be down or slow right now though. On Wed, Apr 23, 2014 at 11:32 AM, raddad555 wblackwell...@comcast.netwrote: Anyone that has worked with SQL has sometime used views to allow the server to do have

Re: A better way to migrate the whole cluster?

I agree it would be nice if this was provided by HBase, but it's already possible to work straight with the HFiles. All you need is a custom hadoop job. A good starting point is https://github.com/mozilla-metrics/akela/blob/master/src/main/java/com/mozilla/hadoop/Backup.java and modify it to

Re: A better way to migrate the whole cluster?

...@gmail.com wrote: Bryan: From javadoc of Backup.java: bq. it favors swallowing exceptions and incrementing counters as opposed to failing Can you share some experience how you handled the errors reported by Backup ? Thanks On Fri, Aug 15, 2014 at 10:38 AM, Bryan Beaudreault

Re: [VOTE] Which Orca representation?

[x] JMS orca (non-binding :)) On Tue, Aug 19, 2014 at 6:53 PM, Esteban Gutierrez este...@cloudera.com wrote: [x] JMS orca -- Cloudera, Inc. On Tue, Aug 19, 2014 at 3:52 PM, Stack st...@duboce.net wrote: Glad to see you are consistent @nkeywal. Here's mine: On Tue, Aug 19,

Re: [DISCUSSION] Convenience binaries bundling Phoenix

As a user I do think this would be pretty convenient, but I wonder if it sets a bad precedent. What sets Phoenix apart from other popular coprocessors in the future? Should they be included too? If so it then adds stress on you guys to come up with guidelines that must be met to be considered

Re: Mock HTableInterface

One possibility is fake-hbase from the guys working on kiji: https://github.com/kijiproject/fake-hbase Alternatively, HTableInterface is just that, an interface. You can put whatever implementation you want behind it. We have many implementations of HTableInterface for a variety of use cases. At

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

Is there any update to this? We just upgraded all of our production clusters from CDH4 to CDH5.4.7 and, not seeing this JIRA listed in the known issues, did not not about this. Now we are seeing perfomance issues across all clusters, as we make heavy use of increments. Can we roll forward to

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

Those log lines have settled down, they may have been related to a cluster-wide forced restart at the time. On Mon, Nov 30, 2015 at 7:59 PM Bryan Beaudreault <bbeaudrea...@hubspot.com> wrote: > We've been doing more debugging of this and have set up the read vs write > han

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

Sorry the second link should be https://gist.github.com/bbeaudreault/2994a748da83d9f75085#file-gistfile1-txt-L579 On Mon, Nov 30, 2015 at 6:10 PM Bryan Beaudreault <bbeaudrea...@hubspot.com> wrote: > https://gist.github.com/bbeaudreault/2994a748da83d9f75085 > > An active h

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

for increments between CDH4.7.1 and CDH5.3.8? On Mon, Nov 30, 2015 at 4:13 PM Stack <st...@duboce.net> wrote: > On Mon, Nov 30, 2015 at 12:54 PM, Bryan Beaudreault < > bbeaudrea...@hubspot.com> wrote: > > > Should this be added as a known issue in the CDH or hb

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

ly we were > > seeing things blocked in mvcc. Now we are seeing them blocked on the > > upsert. > > > > It always follows the same pattern, of 1 active handler in the upsert and > > the rest blocked waiting for it. > > > > On Mon, Nov 30, 2015 at 6:05 PM Stac

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

range. It seems we may be blocking on FSHLog#syncer. https://gist.github.com/bbeaudreault/2994a748da83d9f75085#file-gistfile1-txt-L359 On Mon, Nov 30, 2015 at 11:26 PM Stack <st...@duboce.net> wrote: > Still slow increments though? > > On Mon, Nov 30, 2015 at 5:05 PM, Br

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

} On Tue, Dec 1, 2015 at 12:08 AM Stack <st...@duboce.net> wrote: > Looking at that stack trace, nothing showing as blocked or slowed by > another operation. You have others I could look at Bryan? > St.Ack > > On Mon, Nov 30, 2015 at 8:40 PM, Bryan Beaudreault < &g

Re: Performance degradation between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)

This is great news! Thanks for all of the hard work here, we're excited to put this issue behind us and are happy to see the lesson around improving perf testing. Cheers, Bryan On Mon, Feb 8, 2016 at 1:55 PM Stack wrote: > Let me close out this thread. > > Below is the

Re: [DISCUSS] No regions on Master node in 2.0

I'd like to echo Yu Li. As an operator/user, it is very helpful to be able to run the masters separately. This allows for hot fixes, but also simplifies operations in times of crisis: if there's any real issue, we can restart the masters at will without any fear of impact. If the plan is to

Re: Use experience and performance data of offheap from Alibaba online cluster

Is the backported patch available anywhere? Not seeing it on the referenced JIRA. If it ends up not getting officially backported to branch-1 due to 2.0 around the corner, some of us who build our own deploy may want to integrate into our builds. Thanks! These numbers look great On Fri, Nov 18,

[DISCUSS] InterfaceStability with InterfaceAudience.Public

Hello devs, A recent discussion came up on slack related to a PR I'm working on which adds a new class annotated with InterfaceAudience.Public. It seems like there's some disagreement in terms of what the current documented expectations are for InterfaceStability in this case, and what

Re: [DISCUSS] InterfaceStability with InterfaceAudience.Public

xperimental' APIs. > > So maybe we could add a new LP type called experimental, so these APIs > > could be marked IA.LimitedPrivate("Experimental") and we could use the IS > > annotation then. > > > > This could make developers life easier, but I still a bit worry that, > w

[DISCUSS] InterfaceAudience for protobufs

Hello dev list, This question came up in https://github.com/apache/hbase/pull/3536, where I renamed a field on the BalanceRequest message in Master.proto. This change is backwards compatible to the majority of users, because protobuf does not actually care about the name of the field (only the

Re: [DISCUSS] InterfaceAudience for protobufs

oning" section might have avoided this confusion. On Wed, Aug 11, 2021 at 1:41 PM Stack wrote: > On Tue, Aug 10, 2021 at 10:48 AM Bryan Beaudreault > wrote: > > > Hello dev list, > > > > This question came up in https://github.com/apache/hbase/pull/3536 > &l

Re: [DISCUSS] Removing problematic terms from our project

Sorry to revive a very old thread, but I just stumbled across this and don't see a clear resolution. I wonder if we should create a JIRA from Andrew's summary and treat that as an umbrella encompassing the original 3 JIRAs? I'm also cognizant of the fact that there are rumblings of doing an

Re: [DISCUSS] Removing problematic terms from our project

voting, for necessary > deprecation-release-removal-release cycles where termonology changes impact > one or more of our compatibility guidelines. > > What has been missing since this thread closed with this conclusion? > > Actual patches. > > It's quite easy to advocate

Re: [DISCUSS] StoreFileScanner parallel seek -- productionize or drop?

rote: > > > Unless the potential payoff is significant (yes, this might be hard to > > guess) I would vote for dropping a complex and incomplete (IMHO) > > disabled-by-default 'feature' that is, I would estimate, rarely used if > at > > all, probably not at all. &g

[DISCUSS] StoreFileScanner parallel seek -- productionize or drop?

hbase.storescanner.parallel.seek.enable was added a few years ago in https://issues.apache.org/jira/browse/HBASE-7495, but still defaults to disabled. The description says "Enables StoreFileScanner parallel-seeking in StoreScanner, a feature which can reduce response latency under special

Re: [DISCUSS] How to expose configs for users to tune

ml#important_configurations> > [1]: https://hbase.apache.org/book.html#hbase_default_configurations > <https://hbase.apache.org/book.html#hbase_default_configurations> > > On Tue, Mar 15, 2022 at 4:28 PM Bryan Beaudreault > wrote: > > > Hi devs, > >

[DISCUSS] How to expose configs for users to tune

Hi devs, As a major user of hbase, my company has thousands of clients deployed which use the hbase client to connect to a variety of hbase clusters. We have a common library which handles configuring all clients by setting up the Configuration object prior to creating a Connection. Our library

CI host out of space?

I have gotten a few PR build failures recently that refer to VM terminated. I'm not sure if it's related, but I also caught this job https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4180/4/console which was encountering "no space left on device" Is there some sort of cleanup

Re: [DISCUSS] Use spotless to auto format pom and java code

+1, agreed. It would be nice to backport to branch-2 as well so we can keep the branches somewhat consistent in style at least. On Fri, Mar 25, 2022 at 2:05 PM Huaxiang Sun wrote: > +1, a very nice and helpful feature. > > > > On 2022/03/25 04:04:31 "张铎(Duo Zhang)" wrote: > > Revive. > > > >

Re: [DISCUSS] How to expose configs for users to tune

iguration key management quite dramatically, because currently > it’s > >> ad hoc. > >> > > > > I am supportive of trying such an effort. We'll need to tweak the meaning > > of LP(CONFIG) as we define it currently, but that can be done. I don't > know &g

Re: [DISCUSS] How to expose configs for users to tune

that in a dedicated jira for this topic if desired. On Thu, Mar 24, 2022 at 11:08 AM Bryan Beaudreault wrote: > Thank you both for the input here! > > It seems like we've come to the conclusion that it would be ok to: > > - Update docs around LP(CONFIG) to say that it also encompasse

Re: [DISCUSS] How to expose configs for users to tune

think it's a perfect example of what this LP(Config) API could look like. On Thu, Mar 24, 2022 at 3:47 PM Nick Dimiduk wrote: > One sticking point: ConnectionConfiguration and > AsyncConnectionConfiguration are both IA.Private. > > On Thu, Mar 24, 2022 at 17:21 Bryan Beaudreault >

Re: [DISCUSS] Use spotless to auto format pom and java code

branch-2.5+. > > Will start to work on HBASE-26892 to integrate spotless check in our pre > commit build. > > Bryan Beaudreault 于2022年3月26日周六 > 02:35写道： > > > +1, agreed. It would be nice to backport to branch-2 as well so we can > keep > > the bran

Re: [ANNOUNCE] Please welcome Xiaolin Ha(哈晓琳) to the HBase PMC

Congratulations! On Mon, Apr 11, 2022 at 10:06 AM Huaxiang Sun wrote: > Congratulations, Xiaolin! > > Sent from my iPhone > > > On Apr 11, 2022, at 2:30 AM, Jan Hentschel < > jan.hentsc...@ultratendency.com> wrote: > > > > Congratulations and welcome! > > > > From: 张铎(Duo Zhang) > > Date:

Re: [ANNOUNCE] New HBase committer Bryan Beaudreault

Nick > > On Sat, Apr 9, 2022 at 04:45 张铎(Duo Zhang) wrote: > > > On behalf of the Apache HBase PMC, I am pleased to announce that Bryan > > Beaudreault(bbeaudreault) has accepted the PMC's invitation to become a > > committer on the project. We appreciate all of Bryan's ge

Re: [VOTE] The first release candidate for 2.5.6 (RC0) is available

+1 binding * Signature: ok * Checksum : ok * Rat check (1.8.0_275): ok - mvn clean apache-rat:check * Built from source (1.8.0_275): ok - mvn clean install -DskipTests * Unit tests pass (1.8.0_275): ok - mvn package -P

Re: Time for 2.5.6 and 2.6.0.

Duo Zhang) > wrote: > > > OK, good. So we are good to go I think. > > And we need a release manager for 2.6.x, do you have any interest in > > being a release manager for 2.6.x? :) > > > > Bryan Beaudreault 于2023年10月19日周四 21:22写道： > > > > > > Hello

Re: Time for 2.5.6 and 2.6.0.

called branch-2.6 from branch-2, push > it to github, done :) > > Bryan Beaudreault 于2023年10月20日周五 07:53写道： > > > > I can give it a shot :) > > > > I’ve started looking at the release docs, but don’t see any info on how > to > > create a new release branch.

Re: [VOTE] The first release candidate for hbase-connectors-1.0.1 (RC1) is available

+1 * Signature: ok * Checksum : ok * Rat check (11.0.12): ok - mvn clean apache-rat:check * Built from source (11.0.12): ok - mvn clean install -DskipTests * Unit tests pass (11.0.12): ok - mvn package -P runAllTests On Wed, Oct

Re: [ANNOUNCE] Please welcome Bryan Beaudreault to the HBase PMC

Thanks all! On Tue, Oct 17, 2023 at 2:44 PM Jan Hentschel wrote: > Welcome Bryan! Well deserved. > > From: Duo Zhang > Date: Tuesday, October 17, 2023 at 3:32 AM > To: HBase Dev List , hbase-user < > u...@hbase.apache.org>, user-zh > Subject: [ANNOUNCE] Pleas

Re: Time for 2.5.6 and 2.6.0.

I hate to keep delaying, but it might be nice to wait for https://issues.apache.org/jira/browse/HBASE-28065. It was a pretty big (if long standing) bug for us, and given the solution is ready ( https://github.com/apache/hbase/pull/5384) we might as well get it in our next releases. On Tue, Sep

Re: Time for 2.5.6 and 2.6.0.

; protobuf, there is no technical problem now and I've opened a PR > using > > > > > the 4.1.5-SNAPSHOT version of hbase-thirdparty, > > > > > https://github.com/apache/hbase/pull/5411. There is another > problem > > > > > that we used to exclude

Re: Branching for 2.6 code line (branch-2.6)

gt; Another good news is we are also close to fix the WAL value > > compression issue in HBASE-28028. > > > > Thanks. > > > > Bryan Beaudreault 于2023年6月23日周五 02:47写道： > >> > >> Thanks! > >> > >> We're looking into one other eme

Re: Branching for 2.6 code line (branch-2.6)

We resolved HBASE-28010, so we should be good to go there now. On Sun, Aug 20, 2023 at 7:22 AM Bryan Beaudreault wrote: > I made > https://issues.apache.org/jira/browse/HBASE-28010 a blocker so we don’t > release a broken new feature. We will have it fixed early this week. > >

Re: [DISCUSS] How to expose configs for users to tune

/ConnectionImplementation.java#L173 On Wed, Mar 16, 2022 at 1:46 PM Bryan Beaudreault wrote: > Thanks for your detailed response, Nick! > > > I think that none of my comments address your intended topic: how do we > publish our configuration points as an API that can be consumed by user > applic

Separately configurable client meta rpc timeout

Hi all, We just had a production issue where a user-facing API service had a low hbase.rpc.timeout, and this majorly contributed to a meta hotspotting issue. The issue is, user requests can only be submitted once the necessary RegionLocation is in the MetaCache. But in a meta hotspotting scenario

Re: Separately configurable client meta rpc timeout

Thanks again for your inputs here. I have a PR for this here: https://github.com/apache/hbase/pull/4557 On Mon, Jun 20, 2022 at 5:57 PM Bryan Beaudreault wrote: > Actually, it looks like hbase.rpc.timeout currently applies to the > openScanner call (which is all that's necessary for mos

Re: 2.4.13 this week

Thank you for your hard work and thoroughness here. Should we pause merging to branch-2.4 until you wrap this? I have some things I could merge in the near future, but they are not urgent so I’m happy to wait to backport to 2.4 if it will help. On Wed, Jun 22, 2022 at 11:10 PM Andrew Purtell

Re: 2.4.13 this week

change to 2.5.0 and 2.4.13 respectively? Jira in question: https://issues.apache.org/jira/browse/HBASE-26945 Thanks for your guidance On Thu, Jun 23, 2022 at 11:17 AM Andrew Purtell wrote: > Thank you for thinking of a pause, but that should not be necessary. > > > On Jun 23, 2022, at 3:

Re: [VOTE] First release candidate for HBase 2.4.13 is available for download

The Serializable interface was added to support spark. It used to be Serializable a while ago but then was lost along the way, and we noticed it was causing spark jobs to fail as we upgraded them to hbase2. I believe that should be a compatible change? See

Re: [VOTE] First release candidate for HBase 2.4.13 is available for download

it out for consideration. https://issues.apache.org/jira/browse/HBASE-27170 On Fri, Jul 1, 2022 at 11:17 AM Bryan Beaudreault wrote: > The Serializable interface was added to support spark. It used to be > Serializable a while ago but then was lost along the way, and we noticed it > wa

Re: Aiming for 2.5.0RC1 this Friday

look now is the time. On Mon, Jul 11, 2022 at 9:34 PM Andrew Purtell wrote: > Agreed, lgtm. Thanks for bringing it to our attention. > > On Mon, Jul 11, 2022 at 6:26 PM Bryan Beaudreault > wrote: > > > https://issues.apache.org/jira/browse/HBASE-27149 > <https://issues.a

Re: Aiming for 2.5.0RC1 this Friday

https://issues.apache.org/jira/browse/HBASE-27149 is also patch available, if anyone has time. It's a relatively simple one I think, and helps avoid scanner accumulation under heavy load. On Mon, Jul 11, 2022 at 9:18 PM Andrew Purtell wrote: > We have landed several fixes for referencing

Re: Separately configurable client meta rpc timeout

er call, not retry on the scanner next call. > > IIRC we have a special hbase.client.scanner.timeout.period and also a > special hbase.rpc.timeout for meta? > > Thanks. > > Bryan Beaudreault 于2022年6月1日周三 00:47写道： > > > Hi all, > > > > We just had

Re: Separately configurable client meta rpc timeout

case. > > On Mon, Jun 20, 2022 at 9:09 AM 张铎(Duo Zhang) > wrote: > > > You can see the comments at the top of the method, on why we do not honor > > the rpc timeout, and also not the operation timeout. > > > > So here maybe we should introduce a special scan ti

Re: Separately configurable client meta rpc timeout

Actually, it looks like hbase.rpc.timeout currently applies to the openScanner call (which is all that's necessary for most meta scans, since they are small). So I think we do also need an hbase.client.meta.rpc.timeout config after all. On Mon, Jun 20, 2022 at 4:17 PM Bryan Beaudreault wrote

Re: Aiming for 2.5.0RC1 this Friday

Sounds good. Thanks all for the consideration. On Thu, Jul 14, 2022 at 7:39 PM Andrew Purtell wrote: > HBASE-27204 was filed because we are pushing on RPC. This is good progress. > Let's keep going. I will move out RC1 by one week, to next Friday. > I've also embarked on another (quixotic?)

Re: How to store keystore/truststore password securely?

I agree that it seems insecure to put it directly into the hbase-site.xml. Another reason is due to the RS UI which (helpfully) can print the entire site configuration. We’d need to make sure the password is excluded from that, but better to remove it from site xml altogether. That said, we

Re: Request to join the HBase Slack channel

Sent On Mon, Aug 22, 2022 at 8:44 PM Henry Sowell wrote: > Good evening, > > Following-up here, can I join the Hbase slack channel? I'm excited to > participate. > > Thank you! > > Henry > > On Wed, Aug 17, 2022 at 5:03 PM Henry Sowell > wrote: > > > Hello! > > > > Can I please have access to

Re: About time for 2.5.1

Thanks Andrew! One thing I noticed from 2.5.0 was that a few JIRAs were included in that release which did not have the proper fixVersions set (so did not show up in CHANGES.md). I fixed 4 of them before realizing that may not be the way we should handle it. See [1] for the 4 I fixed (which we

[DISCUSS] Deprecate Scan.setCaching?

Hey team, Is there a reason not to deprecate Scan.setCaching and Scan.getCaching? Way back it was originally the primary way to control how much data is returned per RPC. But it’s awkward for that purpose because rows can be varying sizes. These days setMaxResultSize is a much better API for

Re: [DISCUSS] Release criteria for native TLS support in HBase RPC

enefit of modern investment. > > On Mon, Oct 3, 2022 at 11:43 AM Andor Molnar wrote: > > > Hi Bryan, > > > > We (Cloudera) also planning to start deploying TLS-based clusters to > > production in early November. We'll do feature validation and perf > > benchmarks f

Re: About time for 2.5.1

Thanks for your thoughts. I put a PR up a few moments ago for HBASE-27381. I'll start up threads for discussing the other two points. On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell wrote: > Thanks Bryan. Responses inline. > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault

[DISCUSS] Backporting hbase-backup module to branch-2

Hi again all, We have a relatively full featured backup solution in master branch. It looks like the original development had intended to be included in branch-2 [1], but did not make the deadline for 2.0.0 release and was removed [2]. Later the idea of backporting was forgotten, potentially with

[DISCUSS] Release criteria for native TLS support in HBase RPC

Hi all, The core work for TLS in the HBase RPC is mostly complete. With what's been committed so far, one can connect end-to-end with TLS between client/server and server/server. By default, we also enable mTLS (clients and servers validate the certificate and hostname at handshake). Here is a

Re: Aiming for 2.5.0RC1 this Friday

Are there any remaining blockers for 2.5.0? Also if there's an easy way to view this in JIRA (beyond a custom search for fixVersion=2.5.0) please let me know. On Thu, Jul 14, 2022 at 9:40 PM Bryan Beaudreault wrote: > Sounds good. Thanks all for the consideration. > > On Thu, Jul 14,

Re: [DISCUSS] Allow namespace admins to clone snapshots created by them

I think development is done on TLS. We are just waiting on requested testing. Andor was working on that, but I believe he had some stuff come up at his work. I also want to get backups in place, but there is 1 backwards compatibility issue to work through. Hoping to have that squared away soon.

Re: [ANNOUNCE] New HBase Committer Liangjun He

Congrats! On Sun, Dec 4, 2022 at 2:15 PM Wei-Chiu Chuang wrote: > Congrats! > > On Sun, Dec 4, 2022 at 5:33 AM 宾莉金（binlijin） wrote: > > > Congratulations! > > > > 张铎(Duo Zhang) 于2022年12月3日周六 22:28写道： > > > > > Congratulations! > > > > > > Yu Li 于2022年12月3日周六 21:51写道： > > > > > > > > Hi All,

Re: [DISCUSS] How to deal with the disabling of public sign ups for jira.a.o(enable github issues?)

Should we have them sent to private@? Just thinking in terms of reducing spam to users who put their email and full name on a public list. One thought I had about bug tracking is whether we could use some sort of github -> jira sync. I've seen them used before, where it automatically syncs issues

Re: [DISCUSS] Backporting hbase-backup module to branch-2

e community to reconsider that designation. I > assume this would happen in this case too? > > On Mon, Oct 3, 2022 at 11:03 AM Bryan Beaudreault > wrote: > > > Hi again all, > > > > We have a relatively full featured backup solution in master branch. It > >

Re: [DISCUSS] Time to release 2.5.3 and 2.4.16?

; > Thanks, > Stephen > > On Wed, Jan 18, 2023 at 8:35 PM Andrew Purtell > wrote: > > > Ok. > > > > > On Jan 18, 2023, at 8:28 PM, Bryan Beaudreault > > > wrote: > > > > > > I just submitted a blocker jira: > > > https:

Re: [DISCUSS] Backporting hbase-backup module to branch-2

code line that will release a > new minor. Sounds like a plan. +1 > > > On Tue, Jan 17, 2023 at 5:21 PM Bryan Beaudreault > wrote: > > > Hey all, > > > > I reviewed the entirety of the backport PR. It's almost all net-new code, > > which matches iden

Re: [HELP WANTED] Committers please help reviewing HBASE-27583

Done, thanks for handling this Duo. On Tue, Jan 24, 2023 at 9:27 AM 张铎(Duo Zhang) wrote: > The output of our protoc check eats a lot of space on the jenkins > server and the infra team has already contacted the PMC about this > issue. > > I've opened a PR to remove the -X option when running

Re: [DISCUSS] Time to release 2.5.3 and 2.4.16?

ing to release in svn. > > > > > > 9. Edit download.xml and trigger a new site build. Wait for your > changes > > to go live. > > > > > > 10. Send out a release announcement email. > > > > > > > On Jan 18, 2023, at 8:49 PM, Tak Lon (St

Re: [DISCUSS] Time to release 2.5.3 and 2.4.16?

xecuting the release build via do-release-docker.sh > <http://do-release-docker.sh>, > ran till > > > the mvn site and Java doc generation. > > > > > > > > > > But it failed with 20:05:46 [ERROR] javadoc: error - > > > java.lang.NullPointer

Re: [DISCUSS] Time to release 2.5.3 and 2.4.16?

>> Also the nightly for branch-2.5 > > > >>> https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/ > <https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5> > is > > > >>> green, so IMO this is not a blocker and let's keep

Re: [ANNOUNCE] Please welcome Tak Lon (Stephen) Wu to the HBase PMC

Congrats! On Mon, Jan 30, 2023 at 4:10 AM Balazs Meszaros wrote: > Congratulations! > > On Mon, Jan 30, 2023 at 9:19 AM Jan Hentschel > wrote: > > > Congratulations and welcome! > > > > From: Duo Zhang > > Date: Monday, January 30, 2023 at 3:50 AM > > To: HBase Dev List , hbase-user < > >

Re: [DISCUSS] Time to release 2.5.3 and 2.4.16?

I just submitted a blocker jira: https://issues.apache.org/jira/browse/HBASE-27579 This issue is old, not new to 2.4.x or 2.5.x. But I think we should try to get the fix into the next patch releases, since it is data loss related. On Tue, Jan 17, 2023 at 5:19 PM Andrew Purtell wrote: > I've

[DISCUSS] Remove checkRefCnt for on-heap ByteBuffs?

Hey all, We have a use-case for HFile.Reader at my company. The use-case in question is scanning many hfiles for a small subset of cells, so it mostly is just iterating a large number of HFiles and discarding most of the cells. We recently upgraded that deployable from super old cdh 5.16 (hbase

Re: [DISCUSS] Remove checkRefCnt for on-heap ByteBuffs?

Beaudreault wrote: > For those following along, I’ve submitted an initial PR for this issue. > https://github.com/apache/hbase/pull/5104 > > On Mon, Mar 13, 2023 at 11:46 AM Bryan Beaudreault > wrote: > >> Thanks everyone for chiming in. I submitted >> https://issues.apac

Re: [DISCUSS] Remove checkRefCnt for on-heap ByteBuffs?

For those following along, I’ve submitted an initial PR for this issue. https://github.com/apache/hbase/pull/5104 On Mon, Mar 13, 2023 at 11:46 AM Bryan Beaudreault wrote: > Thanks everyone for chiming in. I submitted > https://issues.apache.org/jira/browse/HBASE-27710 and wil

Re: [ANNOUNCE] New HBase committer Tianhang Tang(唐天航)

Congratulations and welcome! On Thu, Mar 16, 2023 at 12:02 AM 张铎(Duo Zhang) wrote: > On behalf of the Apache HBase PMC, I am pleased to announce that Tianhang > Tang(thangTang) > has accepted the PMC's invitation to become a committer on the project. We > appreciate all > of Tianhang's generous

Re: [DISCUSS] Remove checkRefCnt for on-heap ByteBuffs?

an idea i had. On Mon, Mar 13, 2023 at 2:06 AM Viraj Jasani wrote: > +1, as the numbers suggest significant perf improvement. > > > On Thu, Mar 9, 2023 at 9:36 AM Bryan Beaudreault > wrote: > > > Hey all, > > > > We have a use-case for HFile.Reader at my

Re: Branching for 2.6 code line (branch-2.6)

Primary development on hbase-backup and TLS is complete. There are a couple minor things I may want to add to TLS in the future, such as pluggable cert verification. But those are not needed for initial release IMO. We are almost ready integrating hbase-backup in production. We’ve fixed a few

[DISCUSS] Handle Cell sequenceId in WALPlayer/CellSerialization

Hey all, We've been working on integrating backup/restore into our stack. We have some user tables which override cells -- meaning write the same row/cf/qf/timestamp but with different values. Normally HBase would handle deduping those and returning the most recently written. This is due to the

Re: [DISCUSS] Handle Cell sequenceId in WALPlayer/CellSerialization

context output. To solve this we would pull WALKey.getSequenceId() and set it onto all of the cells in the correspond edit before sending to context. On Thu, Feb 16, 2023 at 5:19 PM Bryan Beaudreault wrote: > Hey all, > > We've been working on integrating backup/restore into our stack. We ha

Re: [DISCUSS] Do not send jira notification emails to dev list?

Personally I like having them. The full stream of all jira notifications on issues@ is too much. It’s useful to keep watching just for open/close to keep informed about what’s happening. On Fri, Apr 21, 2023 at 5:17 AM 张铎(Duo Zhang) wrote: > In the recent board report feedback, a board member

[DISCUSS] Disable HDFS readahead for PREAD reads

Hello team, I recently discovered "hbase.store.reader.no-readahead", which defaults to false (so readahead is enabled). This only applies to PREAD reads, not STREAM reads which always use readahead. When readahead is enabled, the default readahead amount in the DFSClient is 4mb. In my opinion

Re: [NOTICE] Cut branch-3

Nice! So in addition to current conventions around cherry-picking to branch-2*, we should probably almost always cherry-pick changes to branch-3 going forward for now. On Thu, Jun 8, 2023 at 10:43 AM 张铎(Duo Zhang) wrote: > I've already cut branch-3, which is on this commit > >

Re: [DISCUSS] Disable HDFS readahead for PREAD reads

mments about this in the > online book. I'm also in favor of exposing configurable readahead for > STREAM reads, enabling easier experimentation for those keen to do so. > > Thanks, > Nick > > On Fri, Jun 2, 2023 at 9:42 AM Xiaolin Ha wrote: > > > +1 for disable readahead for pread > &

Re: [DISCUSS] Disable HDFS readahead for PREAD reads

I finally got around to this, it's been merged in master, branch-2, and branch-3. I also created https://issues.apache.org/jira/browse/HBASE-28005 for making the readahead configurable for ReadType.STREAM. Thanks again for the input here. On Fri, Jun 9, 2023 at 1:26 PM Bryan Beaudreault wrote

Re: Branching for 2.6 code line (branch-2.6)

t; > > > Netty has some rules about how the exceptions are passed through the > > pipeline(especially the order, forward or backward...) but honestly I > > always forget it just a day later after I finished the code... > > > > Bryan Beaudreault 于2023年6月17日周六

Re: Branching for 2.6 code line (branch-2.6)

is > > > out, we will do a final release of the oldest release line and then > mark it > > > as EOL. > > > > > > So here, I think once we cut branch-2.6 and release 2.6.0, we can do a > > > final release for 2.4.x and mark 2.4.x as EOL. > > &

Re: [DISCUSS] Move stable pointer to 2.5.x

+1 On Fri, May 5, 2023 at 9:42 AM Chintaguntla, Rajeshbabu wrote: > +1 > > Get Outlook for Android > > From: Nick Dimiduk > Sent: Friday, May 5, 2023 3:00:19 PM > To: dev@hbase.apache.org > Subject: Re: [DISCUSS] Move stable pointer to

Re: Handling of fixVersion for umbrella tasks

Ok I can do that but I don’t think that’s quite what Andrew described, unless I misunderstood. On Mon, Jan 22, 2024 at 6:28 PM 张铎(Duo Zhang) wrote: > You should only remove 2.6.0 when fix versions = 2.5.0 :) > > Bryan Beaudreault 于2024年1月23日 周二06:32写道： > > > Andrew, I

Re: Handling of fixVersion for umbrella tasks

ion of 2.5.x when they were cherry-picked. I presume I should leave these alone, but I don't love the inconsistency of it. Since I plan to do all of these updates with a script if possible, I could potentially fix these. Thanks for the guidance. On Tue, Jan 16, 2024 at 12:54 PM Bryan Beaudrea

Re: [DISCUSS] changing our notification settings

My vote would be to disable it, mostly because of the noise from pre-commit hooks that get mirrored over. That said I appreciate what you were trying to do here, and would definitely be in support of your original intention if that were possible to have without the pre-commit noise. On Wed, Jan

Re: [DISCUSS] Pre splitting an existing table to avoid hotspotting issues.

t would be nice if guideposts for multi-way > splitting can be sent over in byte[][]. > > On Wed, Feb 7, 2024 at 10:03 AM Bryan Beaudreault > > wrote: > > > This is the first time I've heard of a region split taking 4 minutes. For > > us, it's always on th

Re: Quick update on 2.6.0

. Am running ITBLL on 2.6.0-SNAPSHOT now. On Thu, Jan 25, 2024 at 9:34 PM Bryan Beaudreault wrote: > Also we need a release of hbase-thirdparty first anyway for some CVEs, so > just trying to avoid having to make another release right afterward for > this other fix. > > On Thu, Ja

Re: [DISCUSS] Pre splitting an existing table to avoid hotspotting issues.

data in table. > > > > If there are already data in the table, you can not always create > > 'empty' regions, as you do not know whether there are already data in > > the given range... > > > > And technically, if you want to split a HFile into more than 2 parts, > >

  1   2   3   4   5   6   >