Re: [DISCUSS] About the topics and time for next meetup

Thanks, Stephen. I'm +1 for the two regional meetups proposal. As per the topics suggested above, I think all are relevant. Some extra thoughts on those: 1) Roadmap - Do we have any roadmap currently published anywhere? - If not, we could use the meetup to start listing what development tasks fol

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

+1 binding [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 31:33 min [INFO] Finished at: 2023-10-19T00:48:18+01:00 [INFO] ~/Downloads/hbase-2.5.6/d

Re: Time for HBase Operator Tools release

Should we also plan to raise the hbase dependency version from 2.4 to 2.5? I think it would be required if we want to add tooling for features only available on 2.5+, such as the proposed by HBASE-26624. Em qua., 22 de nov. de 2023 às 07:14, Viraj Jasani escreveu: > IMO, while this new option is

Re: Debugging slowness in Gets

> > I suspect it is slowness related to storage access. > I was not able to find any logs or tweaks to log "slow storage" > access, does such a thing exist? > I believe I have seen warnings for slow syncs from the hdfs layer, but don't remember any for the read path. And something else that'd hel

Re: [VOTE] The first release candidate for 2.6.0 (RC2) is available

Regarding TestBucketCachePersister flakeyness, I have noticed that last week and had submitted a fix in https://issues.apache.org/jira/browse/HBASE-28458. Em sex., 29 de mar. de 2024 às 15:41, Bryan Beaudreault < bbeaudrea...@apache.org> escreveu: > Thanks. I pushed the addendum fix to HBASE-2765

Re: [VOTE] The first release candidate for 2.6.0 (RC2) is available

r 2, 2024 at 5:23 AM Wellington Chevreuil < > wellington.chevre...@gmail.com> wrote: > > > Regarding TestBucketCachePersister flakeyness, I have noticed that last > > week and had submitted a fix in > > https://issues.apache.org/jira/browse/HBASE-28458. > > >

Re: [DISCUSS] SyncTable is marked as IA.Private?

It seems it was marked that way by HBASE-20212, which bulk marked many public classes as I.A. Private, as part of the efforts to replace the old TestInterfaceAudienceAnnotations validation by warbucks plugin, however I don't see any discussions about which I.A. level should be applied to each class

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

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

Re: +How can I abort pending procedures?

Hi Hossein, for which hbase version are you facing this issue? Removing "/hbase/MasterProcWALs" would probably help sort the mentioned error, but there might be some risk of creating other inconsistencies, depending on which procedures are running. Does list_procedures command show any "running" pr

Re: RegionServer Group based WAL creation & replication

Hi Nikhil, yeah, jira would be more suitable for discussions involving code proposals, with patch reviews. Thinking on the tradeoff from benefits versus impacts/risks of these changes, one thing that comes to my mind is that most of the time, within a normal functioning hdfs as the file system, WA

Re: RegionServer Group based WAL creation & replication

ing WAL output stream create to indicate this. > > > > -- > > Nikhil Bafna | 8095234263 > > > > > > On Mon, Dec 10, 2018 at 4:59 PM Wellington Chevreuil < > > wellington.chevre...@gmail.com> wrote: > > > >> Hi Nikhil, yeah, jira would be

Re: RemoteAdmin/RemoteHTable PUT/POST request are not working in secure cluster

Hi Pankaj, which API version is the client//server running? Line numbers on the stacktrace shared don't seem to match the latest commit for org.apache.hadoop.hbase.rest.client.Client. This NoHttpResponseException suggest the server is not responding. Have you already tried the same command by acces

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

+1 Signature, checksum: OK Build from source: OK Unit tests: OK Rat check: OK Start in standalone mode: OK LTT 1M rows: OK PE sequentialWrite 1M rows: OK Em seg, 18 de fev de 2019 às 14:09, Peter Somogyi escreveu: > +1 > > Signature, checksum: OK > Build from source: OK > Unit tests: OK > Rat c

Re: [VOTE] First release candidate for HBASE 2.2.0 is available

Signature, checksum: OK Build from source: OK Unit tests: OK Rat check: OK Start in standalone mode: OK PE randomWrite 10k rows: OK PE randomRead 10k rows: OK +1 (non binding) Em qui, 7 de mar de 2019 às 19:54, Sean Busbey escreveu: > JMS, could you start a new thread with your upgrade issue so

Re: 2.0.4 to 2.2.0 testing

JMS, if u are still getting stuck to assign meta table, assuming u managed to get an hbck2 jar built, u can try set master to maintenance mode by setting "hbase.master.maintenance_mode" to "true" on master's hbase-site.xml, restart master, then manually bring meta online with hbck2 below command:

Re: Jute buffer size increasing.

This jute buffer len error generally means a given znode being watched/read had grown too large to fit into the buffer. It's not specific to number of watches attached, but amount of info stored in it, for example, too many children znode under a given znode. In order to understand what's behind th

Re:

Slow replication can lead to too many znodes in ZK. These would not be direct children of "/hbase/replication/rs" znode, but of specific RSes replication queue. The "108" showed on your "stat" command output is only the number of RSes, and would not vary, but further znodes under each of those woul

Re: 2.0.4 to 2.2.0 testing

> > server=node3,6,-1 That's an unusual server start code (-1). Maybe that's what's causing meta to never come online, as there will be no SCP for this RS instance. The hbck2 unassigns command Busbey suggested will probably clean assignment for meta, than you could try the "assigns" command

Re: 2.0.4 to 2.2.0 testing

"1588230740" would be the meta region name, not namespace. It seems meta is already online, per below log: ... 2019-03-12 20:53:41,037 INFO [master/node2:6:becomeActiveMaster] master.HMaster: hbase:meta {1588230740 state=OPEN, ts=1552438420570, server= node7.distparser.com,16020,1552421510124}

Re: 2.0.4 to 2.2.0 testing

7;t want to > do anything because the master is initializing :( I tried with ad without > the maintenant flag and I get the same result. > > On HBCK2 side: PleaseHoldException: Master is initializing > On the master side, it just stoped after 5 minutes trying to assign > namespace :(

Re: Replacement for CellUtil.setTimestamp()

You could risk use PrivateCellUtil.setTimestamp() method, but it may break in future releases since PrivateCellUtil is marked as @InterfaceAudience.Private. Another option, given both Put and Delete map to KeyValue cell type, is to check if the Cell type is KeyValue, then do a cast to access setTim

[DISCUSS] hbck2 evolve independently X avoiding having client side logic on hbck2 commands

My understanding on the motivation of moving hbck2 (and potentially other operation related tools) to a separate project was to allow it to evolve on its own cadence, as new interventions to fix previously unforeseen problems were identified, we would now be able to deliver updated tool versions wi

Re: [DISCUSS] hbck2 evolve independently X avoiding having client side logic on hbck2 commands

r something like Allan's servlet loading trick). > > > > Instead of version checking gymnastics in hbck2 could we have the hbck > > service report available feature set? > > > > > Strikes me as overkill at the moment but would be a nice addition. > >

Re: [DISCUSS] hbck2 evolve independently X avoiding having client side logic on hbck2 commands

; I don't see how tracking ever more complicated sets of version numbers in > HBCK2 is going to be simpler than an API in the service that can send back > some strings. > > On Wed, Apr 3, 2019 at 5:46 AM Wellington Chevreuil < > wellington.chevre...@gmail.com> wrote: >

[DISCUSS] Considerations for a hbase-filesystem/hbase-oss alpha release

With proposal from HBASE-22149 committed into hbase-filesystem repo, and with the extra changes proposed in HBASE-22386 and HBASE-22393, our internal tests had shown satisfactory results. It seems functionally usable under the caveat of setting it as the FS for Store Files only, with WALs still on

Re: [DISCUSS] Direction of HBCK2

Interesting, I haven't seen any cases where OfflineMetaRepair was really required, among our customer base (running cdh6.1.x/hbase2.1.1, cdh6.2/hbase2.1.2). Majority of RITs issue I had came with on hbase 2.x were related to APs/SCPs failures, most of which could be sorted with hbck2 commands avail

Re: [DISCUSS] Direction of HBCK2

y tables, get a > brand new installation, recreate the tables and bulkload back the data into > them. Would have been happy to have a OfflineMetaRepair. > > But it's more like an experimental cluster than a production one... > > JMS > > Le mer. 29 mai 2019 à 06:36

Re: [DISCUSS] Direction of HBCK2

> reason > why the table holes happened at that time because the customer didn't want. > > However, IMO, whatever the reason I think we should have a direct way to > fix > holes and overlaps. > > On Wed, May 29, 2019 at 4:57 AM Wellington Chevreuil < > wellington

Re: [DISCUSS] Direction of HBCK2

> > > data. > > > In this case, we can still fix with some combinations of commands > today? > > If > > > so, > > > I would appreciate it if you could suggest the steps to me. > > > > > > > And focus on fixing the main root cause of

Re: [DISCUSS] Direction of HBCK2

after a bug > corrupts > >>>>>>> metadata. It is customary for filesystems and databases to ship > with a > >>>>>> tool > >>>>>>> that attempts recovery after corruption, on the (correct, IMHO) > >>>>>> assumption &

Re: [VOTE] The first HBase 1.3.5 release candidate (RC0) is available

- Tested with "hbase-vote.sh -s https://dist.apache.org/repos/dist/dev/hbase/1.3.5RC0/"; (As Peter mentioned for 1.4.10, the URL from original email is wrong, but I guess it's a small fix on email texting only?): * Signature: ok * Checksum : ok * Rat check (1.8.0_212): ok * Built from sourc

Re: [VOTE] The second HBase 1.4.10 release candidate (RC1) is available

+1 -Tested with "hbase-vote.sh -s https://dist.apache.org/repos/dist/dev/hbase/1.4.10RC1/"; * Signature: ok * Checksum : ok * Rat check (1.8.0_212): ok - mvn clean apache-rat:check * Built from source (1.8.0_212): ok - mvn clean install -DskipTests

[VOTE] First HBase File FileSystem 1.0.0-alpha1-RC0

Please vote on this first HBase FileSystem 1.0.0-alpha1 release candidate. The release files including signatures can be found at: https://dist.apache.org/repos/dist/dev/hbase/hbase-filesystem-1.0.0-alpha1-RC0/ Maven artifacts are available here: https://repository.apache.org/content/repositories

Re: [VOTE] First HBase File FileSystem 1.0.0-alpha1-RC0

; > RAT check passes > > Tests pass, Hadoop 2 > > Tests pass, Hadoop 3 > > > > > > On Fri, Jun 7, 2019 at 7:25 AM Wellington Chevreuil < > > wellington.chevre...@gmail.com> wrote: > > > > > Please vote on this first HBase FileSystem 1.0.0-

Re: [VOTE] The sixth HBase 2.2.0 release candidate (RC6) is available

+1(non-binding) Vote script results: * Signature: ok * Checksum : ok * Rat check (1.8.0_212): ok - mvn clean apache-rat:check * Built from source (1.8.0_212): ok - mvn clean install -DskipTests * Unit tests pass (1.8.0_212): failed - mvn t

[ANNOUNCE] HBase FileSystem 1.0.0-alpha1 is now available for download

The HBase team is happy to announce the immediate availability of Apache HBase FileSystem 1.0.0-alpha1. Apache HBase FileSystem provides additional Apache Hadoop's FileSystem interface implementation, in order to enforce HBase expected FileSystem semantics on top of object-store implementations of

Re: Can we remove OfflineMetaRepair in the master branch and branch-2+?

> > Actually, I have seen several cases where some users ran OfflineMetaRepair > mistakenly in their cluster and corrupted their meta data. > +1 to remove it, just had another of those this morning. There's now HBASE-22680 to eventually port it to operators-tool as well. Em sex, 12 de jul de 2019

Re: [DISCUSS] What to do with branches for EOL versions

I think delete EOM branches and keeping only tags sounds reasonable, but ain't much experienced on releases management, honestly. Do we know what's the standard among most apache projects? Maybe we could follow those? Em seg, 15 de jul de 2019 às 15:27, Josh Elser escreveu: > (Sending this note

Re: Re: [Announce] 张铎 (Duo Zhang) is Apache HBase PMC chair

Congratulations Duo, and thank you and Misty for all the work! On Fri, 19 Jul 2019, 18:13 Pankaj kr, wrote: > Congratulations Duo..!! > > Cheers, > Pankaj > > -Original Message- > From: Justin Ling Mao [mailto:maoling199210...@sina.com] > Sent: 19 July 2019 15:41 > To: dev > Subject: Re

Re: Re: [ANNOUNCE] Please welcome Zheng Hu to the HBase PMC

Good stuff! Congratulations Zheng! Em ter, 6 de ago de 2019 às 10:31, Anoop John escreveu: > Congrats Zheng. > > Anoop > > On Tue, Aug 6, 2019 at 8:52 AM OpenInx wrote: > > > I'm so glad to join the PMC, Apache HBase is a great open source project > > and the > > community is also very nice and

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

+1 (non binding). I also got an UT failing, but tried it individually and same has passed. hbase-vote result: * Signature: ok * Checksum : ok * Rat check (1.8.0_222): ok - mvn clean apache-rat:check * Built from source (1.8.0_222): ok - mvn clean i

Re: [DISCUSS] HBCK2 compatibility

I would favour having hbck2 release branches. Temporary compatibility breaks at compile time may be inevitable if we always point to the latest release. That could cause problems for operators trying to build hbck2 (we are already seeing this happening with our support team). Another argument for s

Re: [DISCUSS] HBCK2 compatibility

elease? > I'm fine with an alpha release but since "HBCK2 should continuously evolve" > it might be better to always use the latest codebase whenever you need to > use the tool. > > On Thu, Aug 29, 2019 at 2:30 PM Wellington Chevreuil < > wellington.chevre...@gmail.

Re: [DISCUSS] HBCK2 compatibility

es? We just need > make sure that it can work with all the releases. If there are missing > methods, we just tell users you can not use several features. > > Wellington Chevreuil 于2019年8月29日周四 > 下午9:39写道： > > > > > > > bq. what would folks think about going with a

Re: [DISCUSS] HBCK2 compatibility

gt; up-to-date hbase release. It has the check version before running a > feature > > in place where it matters. Operators could use this on all currently > > shipping hbase2s? > > > > S > > > > On Thu, Aug 29, 2019 at 11:42 AM Stack wrote: > > >

Re: Region in RIT (CLOSING) , How to fix it ?

The "unassign" procs for each of those regions are waiting on a lock that's currently held by another proc whose id is 21075720: > > 2019-09-02 19:51:29,365 INFO [PEWorker-1] > procedure.MasterProcedureScheduler: Waiting on xlock for > pid=21097026...held by pid=21075720 > You need to figure out

Re: Region in RIT (CLOSING) , How to fix it ?

t; HI , > >> > >> Thanks for your suggection , I used a extreme method solved the issue > . > >> > >> 1. Change the RIT region 'info:state’ value to 'CLOSED' of the meta > table > >> ‘hbase:mata’ > >> 2. Switch over the

Re: [VOTE] The second HBase Operator Tools 1.0.0 release candidate (RC1) is available

+1 (non binding) Built from source: ok Signature: ok Checksum: ok Rat Check: ok Tested below basic commands against hbase versions 2.0.6, 2.16, 2.20 to make sure no regression, all passed: addFsRegionsMissingInMeta, assigns, bypass, reportMissingRegionsInMeta, setRegionState, setTableState,

Re: The fifth HBase 1.5.0 release candidate (RC4) is available

+1 (non binding) * Signature: ok * Checksum : ok * Rat check (1.8.0_222): ok * Built from source (1.8.0_222): ok * UT failures: TestSnapshotFromMaster and TestFIFOCompactionPolicy, both are already on the flaky list; Manually ran create, put, scan. get, disable, drop, flush, list, delete she

Re: [ANNOUNCE] Please welcome Balazs Meszaros to the Apache HBase PMC

Congratulations, Balazs! Em qui, 24 de out de 2019 às 15:34, Sean Busbey escreveu: > On behalf of the Apache HBase PMC I am pleased to announce that > Balazs Meszaros has accepted our invitation to become a PMC member on the > HBase project. We appreciate Balazs stepping up to take more > respon

Re: [ANNOUNCE] Please welcome Sakthi to the Apache HBase PMC

Congratulations, Sakthi! Em qui, 24 de out de 2019 às 12:38, Reid Chan escreveu: > Welcome Sakthi! Congratulations! > > > -- > > Best regards, > R.C > > > > > From: Sean Busbey > Sent: 24 October 2019 04:14 > To: dev; Hbase-User >

Re: [ANNOUNCE] Please welcome Wellington Chevreuil to the Apache HBase PMC

a (BLOOMBERG/ 731 LEX) > Sent: 24 October 2019 04:19 > To: dev@hbase.apache.org > Cc: u...@hbase.apache.org > Subject: Re: [ANNOUNCE] Please welcome Wellington Chevreuil to the Apache > HBase PMC > > Congrats Sakthi and Wellington! > > From: dev@hbase.apache.org At: 10

Re: [ANNOUNCE] New HBase committer Ankit Singhal

Wow, congratulations and welcome, Ankit! Em ter, 12 de nov de 2019 às 16:39, Josh Elser escreveu: > On behalf of the Apache HBase PMC, I'm pleased to announce that Ankit > Singhal has accepted our invitation to become an HBase committer. > > Thanks for all of your contributions to the HBase proj

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

+1 Signature: ok Checksum : ok Rat check (1.8.0_222): ok Built from source (1.8.0_222): ok Tests: ok Run manual CRUD tests deployed on pseudo distributed mode: ok hbase ltt -tn test-2 -families cf -write 5:100:5 -num_keys 100: ok Em qua., 20 de nov. de 2019 às 06:15, Duo Zhang escreveu: > P

Re: [VOTE] First release candidate for Apache HBase 1.4.12

+1 Downloaded source tar, unpacked, then running hbase-vote script all passed, apart from checksum failure, but I then had checksum manually and it is matching. * Signature: ok * Checksum : failed * Rat check (1.8.0_222): ok - mvn clean apache-rat:check * Built fro

Re: [ANNOUNCE] Please welcome Guangxu Cheng the HBase PMC

Congratulations Guangxu! Em seg., 9 de dez. de 2019 às 10:08, Balazs Meszaros escreveu: > Congratulations and welcome Guangxu! > > On Mon, Dec 9, 2019 at 10:51 AM 宾莉金（binlijin） wrote: > > > Congratulations! > > > > Duo Zhang 于2019年12月9日周一 下午5:47写道： > > > > > On behalf of the Apache HBase PMC I

Re: [ANNOUNCE] New HBase committer Viraj Jasani

Congratulations, Viraj! Welcome aboard! Em sex., 27 de dez. de 2019 às 13:02, Peter Somogyi escreveu: > On behalf of the Apache HBase PMC I am pleased to announce that > Viraj Jasani has accepted the PMC's invitation to become a > commiter on the project. > > Thanks so much for the work you've b

Re: [VOTE] The first HBase 2.2.3 release candidate (RC1) is available

+1 (binding) * Signature: ok * Checksum : ok * Rat check (1.8.0_222): ok * Built from source (1.8.0_222): ok - mvn clean install -DskipTests * Unit tests pass (1.8.0_222): ok - mvn package -P runSmallTests Deployed a pseudo-distributed local install: - hbase shell create table,

Re: [DISCUSS] HBASE-18095 - Remove zookeeper dependency in client codepaths

Thanks for the detailed summary, Bharath. I'm +1 for master. Just additional question I have, it wasn't clear for me on the doc/summary: does it consider fallback to ZK based registry, in case of clients running old versions on clusters with this feature enabled? Em qua., 5 de fev. de 2020 às 07:

Re: [DISCUSS] HBASE-18095 - Remove zookeeper dependency in client codepaths

operator might want to foreclose on > > direct ZK access with network or host ACLs but of course this is totally > up > > to them and they are in complete control.) > > > > > On Feb 5, 2020, at 2:12 PM, Wellington Chevreuil < > > wellington.chevre...@gmail.co

Re: [ANNOUNCE] New HBase committer Bharath Vissapragada

Congratulations and welcome to the team, Bharath! Em qui., 6 de fev. de 2020 às 19:25, Esteban Gutierrez escreveu: > Yay! Congratulations Bharath! > > esteban. > -- > Cloudera, Inc. > > > > On Thu, Feb 6, 2020 at 12:07 PM Andrew Purtell > wrote: > > > Congratulations and welcome, Bharath! > > >

Re: [DISCUSS] Defining a process for merging and back-porting feature branches

> > we retain all of the individual commits (one-to-one with Jira sub-tasks). > Mechanically this means something like the following: > (1) squash together all commits that correspond with a single Jira > sub-task, making the history into one commit for one sub-task. > How about also add the fle

Re: [DISCUSS] Defining a process for merging and back-porting feature branches

s what we want. It could work of > course but has downsides. Email explosion. How do I as committer know what > order to apply them in? Confusion as random reviewers see some of the > changes in some of the PRs but miss other changes in others. > > > > On Feb 21, 2020, at 4:13 A

Re: [DISCUSS] Drop support for code contribution via Jira attached patch

+1, can only see benefits of using GitHub PRs over attached patches. On Fri, 21 Feb 2020, 21:33 Andrew Purtell, wrote: > +1 to the idea, having one contribution workflow instead of two is 50% less > confusing (or 100% depending how you count it). > > > applying a patch for local evaluation is m

Re: [VOTE] First Release Candidate for HBase 1.4.13 is available for download

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

Re: [VOTE] First Release Candidate for HBase 1.6.0 is available for download

+1 (binding) hbase-1.6.0 * Signature: ok * Checksum : ok * Rat check (1.8.0_222): ok - mvn clean apache-rat:check * Built from source (1.8.0_222): ok - mvn clean install -DskipTests * Unit tests pass (1.8.0_222): ok - mvn p

Re: [ANNOUNCE] New HBase committer Wei-Chiu Chuang

Congratulations, Wei-Chiu! Welcome! Em qui., 14 de mai. de 2020 às 10:12, Jan Hentschel < jan.hentsc...@ultratendency.com> escreveu: > Congratulations Wei-Chiu and welcome! > > From: Sean Busbey > Reply-To: "dev@hbase.apache.org" > Date: Wednesday, May 13, 2020 at 9:10 PM > To: dev , Hbase-User

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

+1 (binding) * Signature: ok * Checksum : ok * Rat check (1.8.0_222): ok - mvn clean apache-rat:check * Built from source (1.8.0_222): ok - mvn clean install -DskipTests * Unit tests pass (1.8.0_222): ok - mvn package -P runSmallTests Deployed pseudo distributed on local F

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

I agree with Duo regarding the methods that were already marked as IA.private. For the org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad change added by HBASE-24221, the method is marked with @VisibleForTesting and javadoc says "Protected for testing", so maybe it's fine? For

[DISCUSS] IncreasingToUpperBoundRegionSplitPolicy can lead to unpredictable large regions size

While going through the changes proposed on HBASE-24530, we observed IncreasingToUpperBoundRegionSplitPolicy compares hbase.hregion.max.filesize against individual stores within a region when deciding whether to split a region or not. For tables having multiple families, this can lead to regions mu

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

am familiar with it). I can > also > >> help look into other changes if required. > >> > >> Moreover, reg test failure for ReplicationStatusSink, opened Jira > >> HBASE-24594 to have it separate cluster pair setup and not share > resources > >> with TestRepli

Re: [DISCUSS] IncreasingToUpperBoundRegionSplitPolicy can lead to unpredictable large regions size

master, and follow #3 for > >> branch-2 and all active release branches? If it breaks any compatibility > >> rules, then we can go with #3 for all. > >>> > >>> > >>> On 2020/06/19 17:33:14, Andrew Purtell wrote: > >>>> I vote for #3, and

Re: [DISCUSS] VisibleForTesting annotation as it pertains to our API compatibility guidelines

My opinion expressed on the 2.3.0RC0 thread was that @VisibleForTesting would flag class/method/variable as private. I believe the annotation label is pretty suggestive and (I also believe) it's common sense that it should be treated as private by developers. I don't think the fact it's omitted fro

Re: [DISCUSS] VisibleForTesting annotation as it pertains to our API compatibility guidelines

problem, what is the class? I think changing a method > signature for a protected method will only break the compatibility when > users extend the class. In fact, most of the classes in our public API are > not designed to be extended by end users. > > Thanks. > > Wellington Chevreu

Re: [DISCUSS] IncreasingToUpperBoundRegionSplitPolicy can lead to unpredictable large regions size

; > Thank you for pointing this out. I feel even more strongly now this is > a > > > bug. > > > I vote for #3. > > > > > > On Tue, Jun 23, 2020 at 2:42 AM Wellington Chevreuil < > > > wellington.chevre...@gmail.com> wrote: > > > > > > &g

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

I guess following the [DISCUSS] thread, we also need to bring back original signature for "org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad"? Em seg., 22 de jun. de 2020 às 19:22, Wellington Chevreuil < wellington.chevre...@gmail.com> escreveu: > Had su

Re: [DISCUSS] IncreasingToUpperBoundRegionSplitPolicy can lead to unpredictable large regions size

e store file size is for > compaction. > > As long as we just do compactions per family, what is the actual problem > if > > the whole region is too big? > > > > Wellington Chevreuil 于2020年6月24日周三 > > 下午10:56写道： > > > > > The expected behaviour for t

Re: [DISCUSS] Normalizer and pre-split tables

> > The trouble is we ship defaults for all of the `*min*` configs, and right > now there's no way to "unset" them, disable the functionality. Which means > there still isn't a way to support the empty regions use-case without > awkward special-case checks. > HBASE-23562 added a RegionsMerger too

Re: [VOTE] The third HBase 2.2.6 release candidate (RC2) is available

I noticed Version info is showing Chinese characters in both the UI, and the CLI as well: Version 2.2.6, r88c9a386176e2c2b5fd9915d0e9d3ce17d0e456e, 2020年 09月 04日 星期五 09:46:48 CST Would that be an issue for the RC? Em seg., 7 de set. de 2020 às 08:35, Viraj Jasani escreveu: > +1 non-binding >

Re: [VOTE] The second HBase 2.3.2 release candidate (RC1) is available

+1 (binding) * Signature: ok * Checksum : ok * Rat check (1.8.0_181): ok - mvn clean apache-rat:check * Built from source (1.8.0_181): ok - mvn clean install -DskipTests * Unit tests pass (1.8.0_181): ok - mvn package -P runSmallTests Tested deploying on pseudo distributed (local FS

Re: [VOTE] Third HBase 2.3.2 release candidate (RC4) is available

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

Re: [ANNOUNCE] New HBase Committer Zheng Wang(王正)

Congratulations Zheng Wang! Welcome! Em dom., 27 de set. de 2020 às 17:42, Andrew Purtell < andrew.purt...@gmail.com> escreveu: > Congratulations and welcome! > > > On Sep 23, 2020, at 7:25 PM, 张铎(Duo Zhang) > wrote: > > > > On behalf of the Apache HBase PMC, I am pleased to announce that Zheng

Re: [ANNOUNCE] Please welcome Viraj Jasani to the Apache HBase PMC

Welcome onboard, Viraj! Em seg., 5 de out. de 2020 às 17:58, Andrew Purtell escreveu: > On behalf of the Apache HBase PMC I am pleased to announce that > Viraj Jasani has accepted our invitation to become a PMC member on the > HBase project. We appreciate Viraj stepping up to take more > respons

Re: [DISCUSS] Clarifying guidance around Signed-off-by in commit messages

+1 for both suggestions ('Signed-off-by' and 'Reviewed-by'); Em sáb., 21 de nov. de 2020 às 00:15, Stack escreveu: > Thanks for taking the time to do a write up Josh. > > Looks good to me. > > When Sean started in on the 'Signed-off-by:' I didn't get it (especially > after reading the git defini

Re: [ANNOUNCE] New HBase committer Xin Sun

Congratulations and welcome! Em qui., 3 de dez. de 2020 às 09:13, Guanghao Zhang escreveu: > Folks, > > On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun has > accepted the PMC's invitation to become a committer on the project. > > We appreciate all of the great contributio

Re: Project management (JIRA fix version tracking) is in crisis

While no perfect script/tool is available to solve this problem, we may agree on a preferable commiting process to make RM's life less difficult. My take from this thread is that something like below would help: 1) Once a commit happens on any branch, resolve the jira and update fixVersions field

Re: [ANNOUNCE] New HBase Committer Xiaolin Ha(哈晓琳)

Congratulations! Em seg., 17 de mai. de 2021 às 18:04, Nick Dimiduk escreveu: > Congratulations, Xiaolin, and thank you for all your contributions!! > > On Sat, May 15, 2021 at 7:11 AM 张铎(Duo Zhang) > wrote: > > > On behalf of the Apache HBase PMC, I am pleased to announce that Xiaolin > > Ha(s

[DISCUSS] Implement and release HBASE-24749 (an hfile tracker that allows for avoiding renames)

Greetings everyone, HBASE-24749 has been proposed almost a year ago, introducing a new StoreFile tracker as a way to allow for any hbase hfile modifications to be safely completed without needing a file system rename. This seems pretty relevant for deployments over S3 file systems, where rename op

Re: [DISCUSS] Implement and release HBASE-24749 (an hfile tracker that allows for avoiding renames)

l authors, new changes, and/or divide up the development tasks. We > > can certainly offer our time for testing, and can afford the costs of > > testing against the S3 service. > > > > > > On Tue, May 18, 2021 at 12:16 PM Wellington Chevreuil < > > wellington.che

Re: [DISCUSS] Implement and release HBASE-24749 (an hfile tracker that allows for avoiding renames)

Implementing some kind of a test harness that can check compatibility > would > > help here, a similar effort to that of defining standard behaviors of > HDFS > > implementations. > > > > I love this discussion :) > > > > And since the hfile list file will be

Re: [DISCUSS] Implement and release HBASE-24749 (an hfile tracker that allows for avoiding renames)

this level of compatibility. > > > > Either way, we should be clear and up-front about what semantics we > demand. > > Implementing some kind of a test harness that can check compatibility > would > > help here, a similar effort to that of defining standard behaviors of >

master branch issues when running with jdk8

I had faced below errors when trying to run current master branch version on jdk8 (build was also on jdk8): 2021-05-26T23:02:20,202 TRACE [RS-EventLoopGroup-1-1] ipc.NettyRpcServer: Connection /192.168.56.105:44592; caught unexpected downstream exception. > java.lang.NoSuchMethodError: java.nio.By

Re: master branch issues when running with jdk8

uffer signature change and linkage problems is > exactly what motivated me to look into it. > > > On May 27, 2021, at 7:34 AM, Wellington Chevreuil < > wellington.chevre...@gmail.com> wrote: > > > > I had faced below errors when trying to run current master bran

Re: Make new releases due to HBASE-25929?

+1. Although it doesn't seem to cause corruption, losing one or more RSes suddenly or frequently failing compactions can cause a lot of trouble. Em seg., 7 de jun. de 2021 às 03:24, 张铎(Duo Zhang) escreveu: > https://issues.apache.org/jira/browse/HBASE-25929 > > It is a bug which could cause JVM

Re: [DISCUSS] Breakout discussion on storefile tracking storage solutions

I say go for it. Can you create it as a subtask under the umbrella HBASE-24749 and PR to that feature branch? I had been working on the tasks related to avoid "creating files in temp then rename" for flushes and compactions (HBASE-25391 and HBASE-25392), had managed to successfully run it with the

[DISCUSS] Merge HBASE-26067 branch into master, and backport it to base 2 branches

Hello everyone, We have been making progress on the alternative way of tracking store files originally proposed by Duo in HBASE-26067. To briefly summarize it for those not following it, this feature introduces an abstraction layer to track store files still used/needed by store engines, allowing

Re: [DISCUSS] operator tools, HBase 3 and StoreFileTracking

I would prefer the option 2 suggested by Andrew, SFT backported to 2.5 as experimental. Regarding the original "thin client/server master do all the fix " approach for hbck2 mentioned by Duo, that has already been relaxed to include some logic containing functions for some break scenarios where mas

Re: 2.5.0 status update - RC0 coming **tomorrow**

Have one more last minute bug fix: HBASE-27069 - SecureBulkload permission regression. Em seg., 30 de mai. de 2022 às 18:56, Andrew Purtell escreveu: > All known significant issues are resolved. Flaky tests have been found > using repeated suite invocation on x86_64 and aarch64 test hosts. Use t

Re: [DISCUSS] First release candidate for 2.5.0 (RC0) is available for evaluation

> > Even for branch-2.4, we can start placing links into the file, at the top, > leaving the output of the prior process in place below. I think it is fine > to make this change everywhere. Curious what others think. > Sounds ok to me. Regarding CHANGES.md content, it's listing HBASE-26826

Re: [DISCUSS] First release candidate for 2.5.0 (RC0) is available for evaluation

any other bug fix) to > branch-2.5. There are a few other changes committed to the branch post > 2.5.0RC0 too that will get rolled up into RC1 on Monday. > > > On Sun, Jun 5, 2022 at 12:45 PM Wellington Chevreuil < > wellington.chevre...@gmail.com> wrote: > > > >

  1   2   3   4   5   >