Re: [DISCUSS] Moving IA.Public class LossyCounting to IA.Private in all maintenance branches
Looks good to me. S On Thu, May 9, 2019 at 7:02 PM Sean Busbey wrote: > Hi folks! > > just a heads up that a few of us are planning to move a class out of > the public API without a deprecation cycle. > > From the planned release note: > > > The class LossyCounting was unintentionally marked Public but was never > > intended to be part of our public API. This oversight has been corrected > > and LossyCounting is now marked as Private and going forward may be > > subject to additional breaking changes or removal without notice. If you > > have taken a dependency on this class we recommend cloning it locally > into > > your project before upgrading to this release. > > This class was came in via HBASE-19722 and was published in HBase > 1.4.6, 2.0.2, and 2.1.3 (and depending on RC timing might be in > 2.2.0). > > It will move to IA.Private as of 1.4.10, 1.5.0, 2.0.6, 2.1.5 and later > (maybe 2.2.1 depending on RC timing). The class already has > backwards-incompatible changes set to happen in upcoming releases > 1.4.10, 1.5.0, and 2.2.0. > > Please speak up sooner rather than later if you'll have a problem > voting on RCs that include this change, either here or on HBASE-21991. >
Re: I'm about to give up on RMing
Personally when available I spent more time in branch-1 release voting than branch-2 since I think branch-1 is still the stable pointer, also the main usage in production. For the same reason I'm more cautious to give a +1 for branch-1. For me a -1 is not a veto but something noticeable, while I also agree that if I saw a -1 I will wait for RM's explanation or the next RC to cut my own vote, so I myself will change to use +0 in future. I share the same observation that branch-1 releases are hard to attract votes. Probably this reflects that more users (at least PMCs) are waiting for a stable branch-2 release for upgrading rather than a new branch-1 one? If this is the case, then IMHO we should move our stable pointer to branch-2 and EOL branch-1 asap. Or if users are still expecting branch-1 releases but PMC focus more on branch-2, we should figure out a way to resolve the conflict. I'd like to emphasize that I think you're a great RM Andrew (and I could recall the good memories using 0.98 series in production). And I could feel your frustration and my apology if my -1 on 1.5.0 RC is part of the reason (although not on purpose). Best Regards, Yu On Fri, 10 May 2019 at 08:59, Andrew Purtell wrote: > > In that regard I think we should be easier on newcomers. Old timers > should know better and follow up with jiras. > > This is a fair point. > > I would say anyone should feel free to raise a question in the vote thread, > or file a JIRA and mention it. I can only speak for myself but questions or > concerns raised during a vote are not what is frustrating about RMing at > this time. It's great to see the engagement. > > > On Thu, May 9, 2019 at 5:49 PM Artem Ervits wrote: > > > Andrew, I can only imagine how hard it is to be an RM, it takes me hours > to > > review a release let alone roll one. With so many RCs for each branch, > it's > > hard to focus on which branch to target and like you said volunteer time > is > > expensive. Sometimes for new contributors it is uncertain whether the > > observed behavior is intentional or something to be concerned with. I > like > > to point those issues out on a vote and gauge the RM and other voters' > > opinion whether it calls for jira. In that regard I think we should be > > easier on newcomers. Old timers should know better and follow up with > > jiras. Im guilty of calling out certain nits, case in point > > hbase-connectors vote. [1] Luckily feedback loop was quick and we were > able > > to get subsequent issues fixed as part of jiras. It goes back to being > good > > citizen of the community, I'm happy to do reviews but maybe what we > should > > also do for each specific release, call out the issues to test in the > vote > > thread. > > > > That said, question I had for releases below 2.1, do we want to publish > > client binaries [2] or is it something we want to do going forward? > > > > [1] > > > > > https://lists.apache.org/thread.html/2e94a8da7df937e9adf7dc12212ade2eb24f920bb293430e439dde5c@ > > > > > > [2] > > https://issues.apache.org/jira/plugins/servlet/mobile#issue/HBASE-19735 > > > > On Thu, May 9, 2019, 1:42 PM Andrew Purtell wrote: > > > > > Yes, I am already using that phrasing, because it is very difficult to > > get > > > voting interest in any 1.x release candidate. See my other response in > > this > > > regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large > > > aspect of why I find it so frustrating to try and make progress with > > these > > > code lines. And yet we absolutely rely upon them at my place of > > employment, > > > so it appears we are stuck. In other discussions I've discussed why we > > > think HBase 2 is not ready for our production yet. I am perfectly > willing > > > to maintain branch-1s and raise the RMs, but not if every vote is a > slog > > > where I'm out on the street begging for votes, and receiving vetos with > > no > > > assistance for the trouble. I'm pretty sure Francis is in the same > > position > > > with branch-1.3. > > > > > > > > > On Thu, May 9, 2019 at 10:36 AM Sean Busbey wrote: > > > > > > > Personally I don't think we have enough community release voting to > > > > support having closing dates on votes. This was definitely the case > on > > > > 1.2 releases. IIRC it was also true fo the last 1.3 release. > > > > > > > > I think you're already using the "I would like to close this around > > > > XXX" phrasing, but just in case I'm mistaken I figure I should call > it > > > > out. > > > > > > > > On Thu, May 9, 2019 at 12:32 PM Andrew Purtell > > > > wrote: > > > > > > > > > > Sure I will concede treating -1s as vetos is a contributing factor, > > > but I > > > > > think this is just a nod to reality. We have a hard enough time > > > > attracting > > > > > votes on a candidate as it is. When a -1 is cast, maybe I am > > > > insufficiently > > > > > optimistic, but I strongly suspect we won't get enough +1s to > > overcome > > > > it. > > > > > I think that is a realistic
[jira] [Resolved] (HBASE-18373) fstat unimplemented error on Rasbian Jessie
[ https://issues.apache.org/jira/browse/HBASE-18373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-18373. -- Resolution: Not A Problem > fstat unimplemented error on Rasbian Jessie > --- > > Key: HBASE-18373 > URL: https://issues.apache.org/jira/browse/HBASE-18373 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0-alpha-1 > Environment: Raspberry Pi 3 > Rasbian Jessie (latest version) >Reporter: Nathan Green >Priority: Blocker > > I have a Hbase distributed cluster setup on my Raspberry PI cluster (1 x > Namenode & 4 x Datanode) > The stable version of Hbase shell works fine... unfortunately I had hadoop > issues (mismatch of jar files gr) so I have installed latest Hbase & > installed matching version of Hadoop (2.7.1). > HBase itself is up and running and all good. Hbase shell however gives this > error: > pi@pidoop1:/opt/hbase/lib/ruby/irb $ hbase shell > 2017-07-13 12:25:11,722 WARN [main] util.NativeCodeLoader: Unable to load > native-hadoop library for your platform... using builtin-java classes where > applicable > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [jar:file:/opt/hbase/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [jar:file:/opt/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] > HBase Shell > Use "help" to get list of supported commands. > Use "exit" to quit this interactive shell. > Version 2.0.0-alpha-1, rc830a0f47f58d4892dd3300032c8244d6278aecc, Wed Jun 7 > 22:05:17 PDT 2017 > Took 0.0300 seconds > NotImplementedError: fstat unimplemented unsupported or native support failed > to load; see http://wiki.jruby.org/Native-Libraries > initialize at org/jruby/RubyIO.java:1013 > open at org/jruby/RubyIO.java:1154 > initialize at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/input-method.rb:141 > initialize at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/context.rb:70 > initialize at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:426 > initialize at /opt/hbase/lib/ruby/irb/hirb.rb:43 >start at /opt/hbase/bin/hirb.rb:194 >at /opt/hbase/bin/hirb.rb:206 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[DISCUSS] Moving IA.Public class LossyCounting to IA.Private in all maintenance branches
Hi folks! just a heads up that a few of us are planning to move a class out of the public API without a deprecation cycle. >From the planned release note: > The class LossyCounting was unintentionally marked Public but was never > intended to be part of our public API. This oversight has been corrected > and LossyCounting is now marked as Private and going forward may be > subject to additional breaking changes or removal without notice. If you > have taken a dependency on this class we recommend cloning it locally into > your project before upgrading to this release. This class was came in via HBASE-19722 and was published in HBase 1.4.6, 2.0.2, and 2.1.3 (and depending on RC timing might be in 2.2.0). It will move to IA.Private as of 1.4.10, 1.5.0, 2.0.6, 2.1.5 and later (maybe 2.2.1 depending on RC timing). The class already has backwards-incompatible changes set to happen in upcoming releases 1.4.10, 1.5.0, and 2.2.0. Please speak up sooner rather than later if you'll have a problem voting on RCs that include this change, either here or on HBASE-21991.
Re: I'm about to give up on RMing
> In that regard I think we should be easier on newcomers. Old timers should know better and follow up with jiras. This is a fair point. I would say anyone should feel free to raise a question in the vote thread, or file a JIRA and mention it. I can only speak for myself but questions or concerns raised during a vote are not what is frustrating about RMing at this time. It's great to see the engagement. On Thu, May 9, 2019 at 5:49 PM Artem Ervits wrote: > Andrew, I can only imagine how hard it is to be an RM, it takes me hours to > review a release let alone roll one. With so many RCs for each branch, it's > hard to focus on which branch to target and like you said volunteer time is > expensive. Sometimes for new contributors it is uncertain whether the > observed behavior is intentional or something to be concerned with. I like > to point those issues out on a vote and gauge the RM and other voters' > opinion whether it calls for jira. In that regard I think we should be > easier on newcomers. Old timers should know better and follow up with > jiras. Im guilty of calling out certain nits, case in point > hbase-connectors vote. [1] Luckily feedback loop was quick and we were able > to get subsequent issues fixed as part of jiras. It goes back to being good > citizen of the community, I'm happy to do reviews but maybe what we should > also do for each specific release, call out the issues to test in the vote > thread. > > That said, question I had for releases below 2.1, do we want to publish > client binaries [2] or is it something we want to do going forward? > > [1] > > https://lists.apache.org/thread.html/2e94a8da7df937e9adf7dc12212ade2eb24f920bb293430e439dde5c@ > > > [2] > https://issues.apache.org/jira/plugins/servlet/mobile#issue/HBASE-19735 > > On Thu, May 9, 2019, 1:42 PM Andrew Purtell wrote: > > > Yes, I am already using that phrasing, because it is very difficult to > get > > voting interest in any 1.x release candidate. See my other response in > this > > regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large > > aspect of why I find it so frustrating to try and make progress with > these > > code lines. And yet we absolutely rely upon them at my place of > employment, > > so it appears we are stuck. In other discussions I've discussed why we > > think HBase 2 is not ready for our production yet. I am perfectly willing > > to maintain branch-1s and raise the RMs, but not if every vote is a slog > > where I'm out on the street begging for votes, and receiving vetos with > no > > assistance for the trouble. I'm pretty sure Francis is in the same > position > > with branch-1.3. > > > > > > On Thu, May 9, 2019 at 10:36 AM Sean Busbey wrote: > > > > > Personally I don't think we have enough community release voting to > > > support having closing dates on votes. This was definitely the case on > > > 1.2 releases. IIRC it was also true fo the last 1.3 release. > > > > > > I think you're already using the "I would like to close this around > > > XXX" phrasing, but just in case I'm mistaken I figure I should call it > > > out. > > > > > > On Thu, May 9, 2019 at 12:32 PM Andrew Purtell > > > wrote: > > > > > > > > Sure I will concede treating -1s as vetos is a contributing factor, > > but I > > > > think this is just a nod to reality. We have a hard enough time > > > attracting > > > > votes on a candidate as it is. When a -1 is cast, maybe I am > > > insufficiently > > > > optimistic, but I strongly suspect we won't get enough +1s to > overcome > > > it. > > > > I think that is a realistic outlook. When someone comes to the thread > > and > > > > sees a -1, will they bother? The -1 becomes a fait accompli, in my > > > > estimation, so I treat it as a de facto veto. Perhaps this isn't the > > > right > > > > thing to be doing after all. Let me try your suggestion. Currently > > there > > > is > > > > a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, > > > with a > > > > closing date of tomorrow. It doesn't look promising I have to say but > > > let's > > > > let it continue. > > > > > > > > I would like to continue with RM duties. I enjoy it for the most > part. > > It > > > > is the voting that really kind of sucks now. It's hard to attract > > voters. > > > > They make pronouncements without offering any volunteer effort in > > return. > > > > That has become frustrating. > > > > > > > > > > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey > wrote: > > > > > > > > > -1s on a release aren't a veto unless the RM treats them that way. > > > > > Granted, given our current rate of votes they are very hard to > > > > > overcome. I'm painfully aware of the time that goes into putting up > > an > > > > > RC, and I don't think you should continue handling -1s as vetos. > > > > > > > > > > As a voter on RCs I try very hard to reflect on wether or not > > > > > something can be addressed in future releases or via a release > note. > > I > > > > > usually don't
Re: I'm about to give up on RMing
I would +1 a backport of HBASE-19735 to branch-1 if someone wanted to contribute it. It looks like maven should just do the right thing and there is no extra work for the RM; simply another artifact gets published. We can include this in 1.5.0 and later? On Thu, May 9, 2019 at 5:49 PM Artem Ervits wrote: > Andrew, I can only imagine how hard it is to be an RM, it takes me hours to > review a release let alone roll one. With so many RCs for each branch, it's > hard to focus on which branch to target and like you said volunteer time is > expensive. Sometimes for new contributors it is uncertain whether the > observed behavior is intentional or something to be concerned with. I like > to point those issues out on a vote and gauge the RM and other voters' > opinion whether it calls for jira. In that regard I think we should be > easier on newcomers. Old timers should know better and follow up with > jiras. Im guilty of calling out certain nits, case in point > hbase-connectors vote. [1] Luckily feedback loop was quick and we were able > to get subsequent issues fixed as part of jiras. It goes back to being good > citizen of the community, I'm happy to do reviews but maybe what we should > also do for each specific release, call out the issues to test in the vote > thread. > > That said, question I had for releases below 2.1, do we want to publish > client binaries [2] or is it something we want to do going forward? > > [1] > > https://lists.apache.org/thread.html/2e94a8da7df937e9adf7dc12212ade2eb24f920bb293430e439dde5c@ > > > [2] > https://issues.apache.org/jira/plugins/servlet/mobile#issue/HBASE-19735 > > On Thu, May 9, 2019, 1:42 PM Andrew Purtell wrote: > > > Yes, I am already using that phrasing, because it is very difficult to > get > > voting interest in any 1.x release candidate. See my other response in > this > > regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large > > aspect of why I find it so frustrating to try and make progress with > these > > code lines. And yet we absolutely rely upon them at my place of > employment, > > so it appears we are stuck. In other discussions I've discussed why we > > think HBase 2 is not ready for our production yet. I am perfectly willing > > to maintain branch-1s and raise the RMs, but not if every vote is a slog > > where I'm out on the street begging for votes, and receiving vetos with > no > > assistance for the trouble. I'm pretty sure Francis is in the same > position > > with branch-1.3. > > > > > > On Thu, May 9, 2019 at 10:36 AM Sean Busbey wrote: > > > > > Personally I don't think we have enough community release voting to > > > support having closing dates on votes. This was definitely the case on > > > 1.2 releases. IIRC it was also true fo the last 1.3 release. > > > > > > I think you're already using the "I would like to close this around > > > XXX" phrasing, but just in case I'm mistaken I figure I should call it > > > out. > > > > > > On Thu, May 9, 2019 at 12:32 PM Andrew Purtell > > > wrote: > > > > > > > > Sure I will concede treating -1s as vetos is a contributing factor, > > but I > > > > think this is just a nod to reality. We have a hard enough time > > > attracting > > > > votes on a candidate as it is. When a -1 is cast, maybe I am > > > insufficiently > > > > optimistic, but I strongly suspect we won't get enough +1s to > overcome > > > it. > > > > I think that is a realistic outlook. When someone comes to the thread > > and > > > > sees a -1, will they bother? The -1 becomes a fait accompli, in my > > > > estimation, so I treat it as a de facto veto. Perhaps this isn't the > > > right > > > > thing to be doing after all. Let me try your suggestion. Currently > > there > > > is > > > > a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, > > > with a > > > > closing date of tomorrow. It doesn't look promising I have to say but > > > let's > > > > let it continue. > > > > > > > > I would like to continue with RM duties. I enjoy it for the most > part. > > It > > > > is the voting that really kind of sucks now. It's hard to attract > > voters. > > > > They make pronouncements without offering any volunteer effort in > > return. > > > > That has become frustrating. > > > > > > > > > > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey > wrote: > > > > > > > > > -1s on a release aren't a veto unless the RM treats them that way. > > > > > Granted, given our current rate of votes they are very hard to > > > > > overcome. I'm painfully aware of the time that goes into putting up > > an > > > > > RC, and I don't think you should continue handling -1s as vetos. > > > > > > > > > > As a voter on RCs I try very hard to reflect on wether or not > > > > > something can be addressed in future releases or via a release > note. > > I > > > > > usually don't preemptively file a JIRA unless there's a clear > problem > > > > > and solution to be had. > > > > > > > > > > Personally, as a RM I try to gauge wether or not
Re: I'm about to give up on RMing
Andrew, I can only imagine how hard it is to be an RM, it takes me hours to review a release let alone roll one. With so many RCs for each branch, it's hard to focus on which branch to target and like you said volunteer time is expensive. Sometimes for new contributors it is uncertain whether the observed behavior is intentional or something to be concerned with. I like to point those issues out on a vote and gauge the RM and other voters' opinion whether it calls for jira. In that regard I think we should be easier on newcomers. Old timers should know better and follow up with jiras. Im guilty of calling out certain nits, case in point hbase-connectors vote. [1] Luckily feedback loop was quick and we were able to get subsequent issues fixed as part of jiras. It goes back to being good citizen of the community, I'm happy to do reviews but maybe what we should also do for each specific release, call out the issues to test in the vote thread. That said, question I had for releases below 2.1, do we want to publish client binaries [2] or is it something we want to do going forward? [1] https://lists.apache.org/thread.html/2e94a8da7df937e9adf7dc12212ade2eb24f920bb293430e439dde5c@ [2] https://issues.apache.org/jira/plugins/servlet/mobile#issue/HBASE-19735 On Thu, May 9, 2019, 1:42 PM Andrew Purtell wrote: > Yes, I am already using that phrasing, because it is very difficult to get > voting interest in any 1.x release candidate. See my other response in this > regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large > aspect of why I find it so frustrating to try and make progress with these > code lines. And yet we absolutely rely upon them at my place of employment, > so it appears we are stuck. In other discussions I've discussed why we > think HBase 2 is not ready for our production yet. I am perfectly willing > to maintain branch-1s and raise the RMs, but not if every vote is a slog > where I'm out on the street begging for votes, and receiving vetos with no > assistance for the trouble. I'm pretty sure Francis is in the same position > with branch-1.3. > > > On Thu, May 9, 2019 at 10:36 AM Sean Busbey wrote: > > > Personally I don't think we have enough community release voting to > > support having closing dates on votes. This was definitely the case on > > 1.2 releases. IIRC it was also true fo the last 1.3 release. > > > > I think you're already using the "I would like to close this around > > XXX" phrasing, but just in case I'm mistaken I figure I should call it > > out. > > > > On Thu, May 9, 2019 at 12:32 PM Andrew Purtell > > wrote: > > > > > > Sure I will concede treating -1s as vetos is a contributing factor, > but I > > > think this is just a nod to reality. We have a hard enough time > > attracting > > > votes on a candidate as it is. When a -1 is cast, maybe I am > > insufficiently > > > optimistic, but I strongly suspect we won't get enough +1s to overcome > > it. > > > I think that is a realistic outlook. When someone comes to the thread > and > > > sees a -1, will they bother? The -1 becomes a fait accompli, in my > > > estimation, so I treat it as a de facto veto. Perhaps this isn't the > > right > > > thing to be doing after all. Let me try your suggestion. Currently > there > > is > > > a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, > > with a > > > closing date of tomorrow. It doesn't look promising I have to say but > > let's > > > let it continue. > > > > > > I would like to continue with RM duties. I enjoy it for the most part. > It > > > is the voting that really kind of sucks now. It's hard to attract > voters. > > > They make pronouncements without offering any volunteer effort in > return. > > > That has become frustrating. > > > > > > > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > > > > > > > -1s on a release aren't a veto unless the RM treats them that way. > > > > Granted, given our current rate of votes they are very hard to > > > > overcome. I'm painfully aware of the time that goes into putting up > an > > > > RC, and I don't think you should continue handling -1s as vetos. > > > > > > > > As a voter on RCs I try very hard to reflect on wether or not > > > > something can be addressed in future releases or via a release note. > I > > > > usually don't preemptively file a JIRA unless there's a clear problem > > > > and solution to be had. > > > > > > > > Personally, as a RM I try to gauge wether or not to abort an RC > > > > depending on the specifics of the -1 votes cast. There's very little > > > > chance I would sink an RC for a test I can't reproduce. Including a > > > > release note is probably enough. I do tend to be more sympathetic to > > > > compatibility concerns. I think the only way to get meaningful > > > > assurance that the artifacts coming out of the project are what we as > > > > a project support is to support folks voting according to the > standard > > > > they hold without requiring that any
Re: I'm about to give up on RMing
We have a self supporting cohort of RMs, voters, and contributors for branch-2 but not branch-1. I agree this is misaligned with the user centric focus if we define 'user' as someone using a version that has the stable pointer pointing to it. (smile) If anything this thread is a plea from me to build a self supporting cohort of RMs, voters, and contributors for branch-1. It should not be as hard as it has been for myself, Francis, and I think Sean to get 1.x release votes to complete. There should be more contributions to test hygiene and compatibility concerns (when agreed upon) in branch-1. On Thu, May 9, 2019 at 5:42 PM Sergey Shelukhin wrote: > That would be interesting given that in our experience prototyping on > branch-2.1, it is really not ready for production usage. > We fixed many bugs (mostly in the assignment; most either committed or PA > in JIRA, internally we run with all of those) and keep finding new critical > ones all the time (e.g. recently we started running into non-HDFS ProcWAL > corruption, not sure yet why, lost recent repro). > And we haven't even turned on region splitting yet ;) > > So 1.X line appears to be the only actually stable one right now. > > -Original Message- > From: Andrew Purtell > Sent: Thursday, May 9, 2019 10:38 AM > To: dev > Cc: priv...@hbase.apache.org > Subject: Re: I'm about to give up on RMing > > Also, it is my observation that we are really only seeing difficulty > attracting votes when RMs offer a 1.x release candidate. Maybe this implies > the entire branch-1 forest should EOL. This will strand major users still > on 1.x but it appears to be the consensus will of the community, if you > interpret a lack of voting interest in that way. > > > On Thu, May 9, 2019 at 10:32 AM Andrew Purtell > wrote: > > > Sure I will concede treating -1s as vetos is a contributing factor, > > but I think this is just a nod to reality. We have a hard enough time > > attracting votes on a candidate as it is. When a -1 is cast, maybe I > > am insufficiently optimistic, but I strongly suspect we won't get enough > +1s to overcome it. > > I think that is a realistic outlook. When someone comes to the thread > > and sees a -1, will they bother? The -1 becomes a fait accompli, in my > > estimation, so I treat it as a de facto veto. Perhaps this isn't the > > right thing to be doing after all. Let me try your suggestion. > > Currently there is a vote in progress on 1.4.10RC0 with one -1 vote > > and no other votes, with a closing date of tomorrow. It doesn't look > > promising I have to say but let's let it continue. > > > > I would like to continue with RM duties. I enjoy it for the most part. > > It is the voting that really kind of sucks now. It's hard to attract > voters. > > They make pronouncements without offering any volunteer effort in return. > > That has become frustrating. > > > > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > > > >> -1s on a release aren't a veto unless the RM treats them that way. > >> Granted, given our current rate of votes they are very hard to > >> overcome. I'm painfully aware of the time that goes into putting up > >> an RC, and I don't think you should continue handling -1s as vetos. > >> > >> As a voter on RCs I try very hard to reflect on wether or not > >> something can be addressed in future releases or via a release note. > >> I usually don't preemptively file a JIRA unless there's a clear > >> problem and solution to be had. > >> > >> Personally, as a RM I try to gauge wether or not to abort an RC > >> depending on the specifics of the -1 votes cast. There's very little > >> chance I would sink an RC for a test I can't reproduce. Including a > >> release note is probably enough. I do tend to be more sympathetic to > >> compatibility concerns. I think the only way to get meaningful > >> assurance that the artifacts coming out of the project are what we as > >> a project support is to support folks voting according to the > >> standard they hold without requiring that any problems come with a > solution. > >> but that doesn't work if a single -1 can block a release. As you > >> mention, that just becomes a hot potato of work without a volunteer. > >> > >> You've been doing an outsized share of the RM work for a long time > >> Andrew. As someone else who's done some of that work, I can empathize > >> that it's a grind without much noticeable appreciation. I don't have > >> a good answer for what it takes to get us through that discussion. If > >> a break from dealing with release management duties would help you > >> stick around longer contributing in other ways, e.g. evaluating RCs > >> and voting or reviewing features, then please go for it. It will > >> definitely be painful for the project's release cadence, but a > >> regular cadence of releases should be the responsibility of the > >> entire PMC and not one or two individuals. > >> > >> In the specific case of 1.4/1.5 RCs, I haven't caught up on the > >>
RE: I'm about to give up on RMing
That would be interesting given that in our experience prototyping on branch-2.1, it is really not ready for production usage. We fixed many bugs (mostly in the assignment; most either committed or PA in JIRA, internally we run with all of those) and keep finding new critical ones all the time (e.g. recently we started running into non-HDFS ProcWAL corruption, not sure yet why, lost recent repro). And we haven't even turned on region splitting yet ;) So 1.X line appears to be the only actually stable one right now. -Original Message- From: Andrew Purtell Sent: Thursday, May 9, 2019 10:38 AM To: dev Cc: priv...@hbase.apache.org Subject: Re: I'm about to give up on RMing Also, it is my observation that we are really only seeing difficulty attracting votes when RMs offer a 1.x release candidate. Maybe this implies the entire branch-1 forest should EOL. This will strand major users still on 1.x but it appears to be the consensus will of the community, if you interpret a lack of voting interest in that way. On Thu, May 9, 2019 at 10:32 AM Andrew Purtell wrote: > Sure I will concede treating -1s as vetos is a contributing factor, > but I think this is just a nod to reality. We have a hard enough time > attracting votes on a candidate as it is. When a -1 is cast, maybe I > am insufficiently optimistic, but I strongly suspect we won't get enough +1s > to overcome it. > I think that is a realistic outlook. When someone comes to the thread > and sees a -1, will they bother? The -1 becomes a fait accompli, in my > estimation, so I treat it as a de facto veto. Perhaps this isn't the > right thing to be doing after all. Let me try your suggestion. > Currently there is a vote in progress on 1.4.10RC0 with one -1 vote > and no other votes, with a closing date of tomorrow. It doesn't look > promising I have to say but let's let it continue. > > I would like to continue with RM duties. I enjoy it for the most part. > It is the voting that really kind of sucks now. It's hard to attract voters. > They make pronouncements without offering any volunteer effort in return. > That has become frustrating. > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > >> -1s on a release aren't a veto unless the RM treats them that way. >> Granted, given our current rate of votes they are very hard to >> overcome. I'm painfully aware of the time that goes into putting up >> an RC, and I don't think you should continue handling -1s as vetos. >> >> As a voter on RCs I try very hard to reflect on wether or not >> something can be addressed in future releases or via a release note. >> I usually don't preemptively file a JIRA unless there's a clear >> problem and solution to be had. >> >> Personally, as a RM I try to gauge wether or not to abort an RC >> depending on the specifics of the -1 votes cast. There's very little >> chance I would sink an RC for a test I can't reproduce. Including a >> release note is probably enough. I do tend to be more sympathetic to >> compatibility concerns. I think the only way to get meaningful >> assurance that the artifacts coming out of the project are what we as >> a project support is to support folks voting according to the >> standard they hold without requiring that any problems come with a solution. >> but that doesn't work if a single -1 can block a release. As you >> mention, that just becomes a hot potato of work without a volunteer. >> >> You've been doing an outsized share of the RM work for a long time >> Andrew. As someone else who's done some of that work, I can empathize >> that it's a grind without much noticeable appreciation. I don't have >> a good answer for what it takes to get us through that discussion. If >> a break from dealing with release management duties would help you >> stick around longer contributing in other ways, e.g. evaluating RCs >> and voting or reviewing features, then please go for it. It will >> definitely be painful for the project's release cadence, but a >> regular cadence of releases should be the responsibility of the >> entire PMC and not one or two individuals. >> >> In the specific case of 1.4/1.5 RCs, I haven't caught up on the >> current status yet but I'm happy to take a look and break off a >> discussion thread for whatever is currently blocking things. >> >> On Thu, May 9, 2019 at 11:41 AM Andrew Purtell >> >> wrote: >> > >> > .. a code base to the RM role. I don't believe vetos for RCs for >> > flaky tests should be considered valid reason to vote -1. I think >> > we may be erring toward excessively maximal interpretation of >> > compatibility guidelines in some cases. At any rate, where does the >> > responsibility lie for fixing the issues? And do voters consider >> > the personal cost to the >> RM >> > in terms of time and attention in rolling the RC when deciding to >> > vote >> -1? >> > The -1 vote has a cost. It requires the RM to restart the RC. My >> impression >> > is
[jira] [Resolved] (HBASE-22389) Revert HBASE-19275 TestSnapshotFileCache never worked properly on branch-1
[ https://issues.apache.org/jira/browse/HBASE-22389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York resolved HBASE-22389. --- Resolution: Fixed Fix Version/s: 1.4.11 1.5.0 > Revert HBASE-19275 TestSnapshotFileCache never worked properly on branch-1 > -- > > Key: HBASE-22389 > URL: https://issues.apache.org/jira/browse/HBASE-22389 > Project: HBase > Issue Type: Bug >Affects Versions: 1.5.0 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Fix For: 1.5.0, 1.4.11 > > > This commit seems broken on branch-1. > https://github.com/apache/hbase/commit/d80d3fa45487fedf203c7144e8267753e4d53529#diff-ae046012dd310fc116a729bf36c7df81 > seems to have fixed the issue that the other HBASE-19275 patches fixed, but > when HBASE-19275 was applied to branch-1 it appears to have reverted this > code: > https://github.com/apache/hbase/commit/e8e4beacb039299a9e56cd355e3ada08784a7acb#diff-ae046012dd310fc116a729bf36c7df81 > meaning the tests always pass again. > [~apurtell] [~xucang] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22391) Fix flaky tests from TestFromClientSide
Xu Cang created HBASE-22391: --- Summary: Fix flaky tests from TestFromClientSide Key: HBASE-22391 URL: https://issues.apache.org/jira/browse/HBASE-22391 Project: HBase Issue Type: New Feature Components: test Affects Versions: 2.0.5, 3.0.0, 1.5.1 Reporter: Xu Cang tests in TestFromClientSide.java in general are flaky due to the reason that after createTable, they did not wait for table to be ready before adding data into table. Found this issue when working on HBASE-22274 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21800) RegionServer aborted due to NPE from MetaTableMetrics coprocessor
[
https://issues.apache.org/jira/browse/HBASE-21800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-21800.
Resolution: Fixed
> RegionServer aborted due to NPE from MetaTableMetrics coprocessor
> -
>
> Key: HBASE-21800
> URL: https://issues.apache.org/jira/browse/HBASE-21800
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, meta, metrics, Operability
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Critical
> Labels: Meta
> Fix For: 3.0.0, 1.5.0, 2.2.0, 2.3.0, 1.4.10
>
> Attachments: hbase-21800.branch-1.001.patch,
> hbase-21800.branch-1.002.patch, hbase-21800.branch-1.003.patch,
> hbase-21800.branch-1.004.patch, hbase-21800.master.001.patch,
> hbase-21800.master.002.patch, hbase-21800.master.003.patch
>
>
> I was just playing around the code, trying to capture "Top k" table metrics
> from MetaMetrics, when I bumped into this issue. Though currently we are not
> capturing "Top K" table metrics, but we can encounter this issue because of
> the "Top k Clients" that is implemented using the LossyAlgo.
>
> RegionServer gets aborted due to a NPE from MetaTableMetrics coprocessor. The
> log looks somewhat like this:
> {code:java}
> 2019-01-28 23:31:10,311 ERROR
> [RpcServer.priority.FPBQ.Fifo.handler=19,queue=1,port=16020]
> coprocessor.CoprocessorHost: The coprocessor
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics threw
> java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.markMeterIfPresent(MetaTableMetrics.java:123)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.tableMetricRegisterAndMark2(MetaTableMetrics.java:233)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.preGetOp(MetaTableMetrics.java:82)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:840)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:551)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:625)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preGet(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2608)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2547)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41998)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:413)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> 2019-01-28 23:31:10,314 ERROR
> [RpcServer.priority.FPBQ.Fifo.handler=19,queue=1,port=16020]
> regionserver.HRegionServer: * ABORTING region server
> 10.0.0.24,16020,1548747043814: The coprocessor
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics threw
> java.lang.NullPointerException *
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.markMeterIfPresent(MetaTableMetrics.java:123)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.tableMetricRegisterAndMark2(MetaTableMetrics.java:233)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.preGetOp(MetaTableMetrics.java:82)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:840)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:551)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:625)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preGet(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2608)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2547)
> at
>
Re: [VOTE] The first HBase 1.4.10 release candidate (RC0) is available
Thank you, I will follow up on those issues. On Thu, May 9, 2019 at 1:38 PM Peter Somogyi wrote: > Sorry I didn't mention it here, but when voting I reopened HBASE-21800 and > HBASE-21991. These introduced changes to LossyCounting, which is currently > IA.Public. I asked the contributor on JIRA to provide a patch for the > incompatibility. Maybe this class shouldn't be IA.Public; I'd be fine with > that here. But we should make sure we either make it not public with a > proper release note or fix it. > > On Thu, May 9, 2019 at 8:41 PM Andrew Purtell > wrote: > > > As was pointed out on another thread it's my personal take to be treating > > -1 votes as vetos, so as point of order this is not a veto. Apologies for > > causing any confusion there. As the remainder of my response, I think the > > call to courtesy in those words should stand and are submitted for your > > consideration. > > > > On Thu, May 9, 2019 at 9:29 AM Andrew Purtell > > wrote: > > > > > Are you referring to the changes I called out in HBASE-22215 or > something > > > else? If HBASE-22215 please do us the courtesy of reopening it with > your > > > objection, because the change was given due consideration there > already. > > > > > > Additive changes to LP classes are allowed, I believe, but you will > need > > > to be more specific. I can only guess what you are looking at. > > > > > > Currently this veto is not valid because it does not indicate what the > > > actual problem is. Please file a JIRA with your instructions to remedy > > the > > > problem. At the very least list the items you feel are at issue. > > > > > > > On May 9, 2019, at 2:53 AM, Peter Somogyi > wrote: > > > > > > > > -1 > > > > > > > > Compatibility report shows removed methods and changed constructor > > > > signature for a IA.Public interface. There are also a couple of > changes > > > for > > > > IA.LP classes. > > > > > > > > Also checked: > > > > Checksum, signature OK > > > > Rat check OK > > > > Unit tests OK > > > > Simple shell commands OK > > > > LTT 1M rows OK > > > > Master, RS UI OK > > > > > > > >> On Sat, May 4, 2019 at 3:07 AM Andrew Purtell > > > wrote: > > > >> > > > >> Pardon me, there is a typo on the close date for the vote. I would > > like > > > to > > > >> close the vote by or on May 10, 2019. The tenth, not the nineteenth, > > > thank > > > >> you. > > > >> > > > >> > > > >>> On Fri, May 3, 2019 at 6:04 PM Andrew Purtell > > > > wrote: > > > >>> > > > >>> The first HBase 1.4.10 release candidate (RC0) is available for > > > download > > > >>> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/ > and > > > >>> Maven artifacts are available in the temporary repository > > > >>> > > https://repository.apache.org/content/repositories/orgapachehbase-1310 > > > . > > > >>> > > > >>> The git tag corresponding to the candidate is '1.4.10RC0' > > (8a597e477e). > > > >>> > > > >>> A detailed source and binary compatibility report for this release > is > > > >>> available for your review at > > > >>> > > > >> > > > > > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/compat-check-report.html > > > >>> . There are no reported compatibility issues of concern. The > changes > > to > > > >>> Public annotated class MultiRowRangeFilter are reported as low > impact > > > by > > > >>> the compatibility checker tool and were discussed and allowed on > > > >>> . > > > >>> > > > >>> A list of the 57 issues resolved in this release can be found at > > > >>> https://s.apache.org/7gSD . > > > >>> > > > >>> Please try out the candidate and vote +1/0/-1. > > > >>> > > > >>> The vote will be open for at least 72 hours. Unless objection I > will > > > try > > > >>> to close it Friday May 19, 2019 if we have sufficient votes. > > > >>> > > > >>> Prior to making this announcement I made the following preflight > > > checks: > > > >>> > > > >>>RAT check passes (7u80) > > > >>>Unit test suite passes 5/5 (7u80, 8u172) > > > >>>LTT load 100M rows with 100% verification and 20% updates > (8u181) > > > >>> > > > >>> > > > >>> -- > > > >>> Best regards, > > > >>> Andrew > > > >>> > > > >>> > > > >> > > > >> -- > > > >> Best regards, > > > >> Andrew > > > >> > > > >> Words like orphans lost among the crosstalk, meaning torn from > truth's > > > >> decrepit hands > > > >> - A23, Crosstalk > > > >> > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [VOTE] The first HBase 1.4.10 release candidate (RC0) is available
Sorry I didn't mention it here, but when voting I reopened HBASE-21800 and HBASE-21991. These introduced changes to LossyCounting, which is currently IA.Public. I asked the contributor on JIRA to provide a patch for the incompatibility. Maybe this class shouldn't be IA.Public; I'd be fine with that here. But we should make sure we either make it not public with a proper release note or fix it. On Thu, May 9, 2019 at 8:41 PM Andrew Purtell wrote: > As was pointed out on another thread it's my personal take to be treating > -1 votes as vetos, so as point of order this is not a veto. Apologies for > causing any confusion there. As the remainder of my response, I think the > call to courtesy in those words should stand and are submitted for your > consideration. > > On Thu, May 9, 2019 at 9:29 AM Andrew Purtell > wrote: > > > Are you referring to the changes I called out in HBASE-22215 or something > > else? If HBASE-22215 please do us the courtesy of reopening it with your > > objection, because the change was given due consideration there already. > > > > Additive changes to LP classes are allowed, I believe, but you will need > > to be more specific. I can only guess what you are looking at. > > > > Currently this veto is not valid because it does not indicate what the > > actual problem is. Please file a JIRA with your instructions to remedy > the > > problem. At the very least list the items you feel are at issue. > > > > > On May 9, 2019, at 2:53 AM, Peter Somogyi wrote: > > > > > > -1 > > > > > > Compatibility report shows removed methods and changed constructor > > > signature for a IA.Public interface. There are also a couple of changes > > for > > > IA.LP classes. > > > > > > Also checked: > > > Checksum, signature OK > > > Rat check OK > > > Unit tests OK > > > Simple shell commands OK > > > LTT 1M rows OK > > > Master, RS UI OK > > > > > >> On Sat, May 4, 2019 at 3:07 AM Andrew Purtell > > wrote: > > >> > > >> Pardon me, there is a typo on the close date for the vote. I would > like > > to > > >> close the vote by or on May 10, 2019. The tenth, not the nineteenth, > > thank > > >> you. > > >> > > >> > > >>> On Fri, May 3, 2019 at 6:04 PM Andrew Purtell > > wrote: > > >>> > > >>> The first HBase 1.4.10 release candidate (RC0) is available for > > download > > >>> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/ and > > >>> Maven artifacts are available in the temporary repository > > >>> > https://repository.apache.org/content/repositories/orgapachehbase-1310 > > . > > >>> > > >>> The git tag corresponding to the candidate is '1.4.10RC0' > (8a597e477e). > > >>> > > >>> A detailed source and binary compatibility report for this release is > > >>> available for your review at > > >>> > > >> > > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/compat-check-report.html > > >>> . There are no reported compatibility issues of concern. The changes > to > > >>> Public annotated class MultiRowRangeFilter are reported as low impact > > by > > >>> the compatibility checker tool and were discussed and allowed on > > >>> . > > >>> > > >>> A list of the 57 issues resolved in this release can be found at > > >>> https://s.apache.org/7gSD . > > >>> > > >>> Please try out the candidate and vote +1/0/-1. > > >>> > > >>> The vote will be open for at least 72 hours. Unless objection I will > > try > > >>> to close it Friday May 19, 2019 if we have sufficient votes. > > >>> > > >>> Prior to making this announcement I made the following preflight > > checks: > > >>> > > >>>RAT check passes (7u80) > > >>>Unit test suite passes 5/5 (7u80, 8u172) > > >>>LTT load 100M rows with 100% verification and 20% updates (8u181) > > >>> > > >>> > > >>> -- > > >>> Best regards, > > >>> Andrew > > >>> > > >>> > > >> > > >> -- > > >> Best regards, > > >> Andrew > > >> > > >> Words like orphans lost among the crosstalk, meaning torn from truth's > > >> decrepit hands > > >> - A23, Crosstalk > > >> > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
[jira] [Created] (HBASE-22390) backport HBASE-22190 to branch-1
Zach York created HBASE-22390: - Summary: backport HBASE-22190 to branch-1 Key: HBASE-22390 URL: https://issues.apache.org/jira/browse/HBASE-22390 Project: HBase Issue Type: Bug Affects Versions: 1.4.10, 1.5.0 Reporter: Zach York Assignee: Zach York HBASE-22190 was only applied to branch-2+ while the bug exists in branch-1 as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-22330) Backport HBASE-20724 (Sometimes some compacted storefiles are still opened after region failover) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-22330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Singh Chouhan reopened HBASE-22330: Hardening the test > Backport HBASE-20724 (Sometimes some compacted storefiles are still opened > after region failover) to branch-1 > - > > Key: HBASE-22330 > URL: https://issues.apache.org/jira/browse/HBASE-22330 > Project: HBase > Issue Type: Sub-task > Components: Compaction, regionserver >Affects Versions: 1.5.0, 1.4.9, 1.3.4 >Reporter: Andrew Purtell >Assignee: Abhishek Singh Chouhan >Priority: Major > Fix For: 1.5.0, 1.3.5, 1.4.11 > > Attachments: HBASE-22330.branch-1.001.patch, > HBASE-22330.branch-1.002.patch, HBASE-22330.branch-1.3.001.patch > > > There appears to be a race condition between close and split which when > combined with a side effect of HBASE-20704, leads to the parent region store > files getting archived and cleared while daughter regions still have > references to those parent region store files. > Here is the timeline of events observed for an affected region: > # RS1 faces ZooKeeper connectivity issue for master node and starts shutting > itself down. As part of this it starts to close the store and clean up the > compacted files (File A) > # Master starts bulk assigning regions and assign parent region to RS2 > # Region opens on RS2 and ends up opening compacted store file(s) (suspect > this is due to HBASE-20724) > # Now split happens and daughter regions open on RS2 and try to run a > compaction as part of post open > # Split request at this point is complete. However now archiving proceeds on > RS1 and ends up archiving the store file that is referenced by the daughter. > Compaction fails due to FileNotFoundException and all subsequent attempts to > open the region will fail until manual resolution. > We think having HBASE-20724 would help in such situations since we won't end > up loading compacted store files in the first place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22389) Revert HBASE-19275 TestSnapshotFileCache never worked properly on branch-1
Zach York created HBASE-22389: - Summary: Revert HBASE-19275 TestSnapshotFileCache never worked properly on branch-1 Key: HBASE-22389 URL: https://issues.apache.org/jira/browse/HBASE-22389 Project: HBase Issue Type: Bug Affects Versions: 1.5.0 Reporter: Zach York Assignee: Zach York This commit seems broken on branch-1. https://github.com/apache/hbase/commit/d80d3fa45487fedf203c7144e8267753e4d53529#diff-ae046012dd310fc116a729bf36c7df81 seems to have fixed the issue that the other HBASE-19275 patches fixed, but when HBASE-19275 was applied to branch-1 it appears to have reverted this code: https://github.com/apache/hbase/commit/e8e4beacb039299a9e56cd355e3ada08784a7acb#diff-ae046012dd310fc116a729bf36c7df81 meaning the tests always pass again. [~apurtell] [~xucang] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] The first HBase 1.4.10 release candidate (RC0) is available
As was pointed out on another thread it's my personal take to be treating -1 votes as vetos, so as point of order this is not a veto. Apologies for causing any confusion there. As the remainder of my response, I think the call to courtesy in those words should stand and are submitted for your consideration. On Thu, May 9, 2019 at 9:29 AM Andrew Purtell wrote: > Are you referring to the changes I called out in HBASE-22215 or something > else? If HBASE-22215 please do us the courtesy of reopening it with your > objection, because the change was given due consideration there already. > > Additive changes to LP classes are allowed, I believe, but you will need > to be more specific. I can only guess what you are looking at. > > Currently this veto is not valid because it does not indicate what the > actual problem is. Please file a JIRA with your instructions to remedy the > problem. At the very least list the items you feel are at issue. > > > On May 9, 2019, at 2:53 AM, Peter Somogyi wrote: > > > > -1 > > > > Compatibility report shows removed methods and changed constructor > > signature for a IA.Public interface. There are also a couple of changes > for > > IA.LP classes. > > > > Also checked: > > Checksum, signature OK > > Rat check OK > > Unit tests OK > > Simple shell commands OK > > LTT 1M rows OK > > Master, RS UI OK > > > >> On Sat, May 4, 2019 at 3:07 AM Andrew Purtell > wrote: > >> > >> Pardon me, there is a typo on the close date for the vote. I would like > to > >> close the vote by or on May 10, 2019. The tenth, not the nineteenth, > thank > >> you. > >> > >> > >>> On Fri, May 3, 2019 at 6:04 PM Andrew Purtell > wrote: > >>> > >>> The first HBase 1.4.10 release candidate (RC0) is available for > download > >>> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/ and > >>> Maven artifacts are available in the temporary repository > >>> https://repository.apache.org/content/repositories/orgapachehbase-1310 > . > >>> > >>> The git tag corresponding to the candidate is '1.4.10RC0' (8a597e477e). > >>> > >>> A detailed source and binary compatibility report for this release is > >>> available for your review at > >>> > >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/compat-check-report.html > >>> . There are no reported compatibility issues of concern. The changes to > >>> Public annotated class MultiRowRangeFilter are reported as low impact > by > >>> the compatibility checker tool and were discussed and allowed on > >>> . > >>> > >>> A list of the 57 issues resolved in this release can be found at > >>> https://s.apache.org/7gSD . > >>> > >>> Please try out the candidate and vote +1/0/-1. > >>> > >>> The vote will be open for at least 72 hours. Unless objection I will > try > >>> to close it Friday May 19, 2019 if we have sufficient votes. > >>> > >>> Prior to making this announcement I made the following preflight > checks: > >>> > >>>RAT check passes (7u80) > >>>Unit test suite passes 5/5 (7u80, 8u172) > >>>LTT load 100M rows with 100% verification and 20% updates (8u181) > >>> > >>> > >>> -- > >>> Best regards, > >>> Andrew > >>> > >>> > >> > >> -- > >> Best regards, > >> Andrew > >> > >> Words like orphans lost among the crosstalk, meaning torn from truth's > >> decrepit hands > >> - A23, Crosstalk > >> > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: I'm about to give up on RMing
Yes, I am already using that phrasing, because it is very difficult to get voting interest in any 1.x release candidate. See my other response in this regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large aspect of why I find it so frustrating to try and make progress with these code lines. And yet we absolutely rely upon them at my place of employment, so it appears we are stuck. In other discussions I've discussed why we think HBase 2 is not ready for our production yet. I am perfectly willing to maintain branch-1s and raise the RMs, but not if every vote is a slog where I'm out on the street begging for votes, and receiving vetos with no assistance for the trouble. I'm pretty sure Francis is in the same position with branch-1.3. On Thu, May 9, 2019 at 10:36 AM Sean Busbey wrote: > Personally I don't think we have enough community release voting to > support having closing dates on votes. This was definitely the case on > 1.2 releases. IIRC it was also true fo the last 1.3 release. > > I think you're already using the "I would like to close this around > XXX" phrasing, but just in case I'm mistaken I figure I should call it > out. > > On Thu, May 9, 2019 at 12:32 PM Andrew Purtell > wrote: > > > > Sure I will concede treating -1s as vetos is a contributing factor, but I > > think this is just a nod to reality. We have a hard enough time > attracting > > votes on a candidate as it is. When a -1 is cast, maybe I am > insufficiently > > optimistic, but I strongly suspect we won't get enough +1s to overcome > it. > > I think that is a realistic outlook. When someone comes to the thread and > > sees a -1, will they bother? The -1 becomes a fait accompli, in my > > estimation, so I treat it as a de facto veto. Perhaps this isn't the > right > > thing to be doing after all. Let me try your suggestion. Currently there > is > > a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, > with a > > closing date of tomorrow. It doesn't look promising I have to say but > let's > > let it continue. > > > > I would like to continue with RM duties. I enjoy it for the most part. It > > is the voting that really kind of sucks now. It's hard to attract voters. > > They make pronouncements without offering any volunteer effort in return. > > That has become frustrating. > > > > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > > > > > -1s on a release aren't a veto unless the RM treats them that way. > > > Granted, given our current rate of votes they are very hard to > > > overcome. I'm painfully aware of the time that goes into putting up an > > > RC, and I don't think you should continue handling -1s as vetos. > > > > > > As a voter on RCs I try very hard to reflect on wether or not > > > something can be addressed in future releases or via a release note. I > > > usually don't preemptively file a JIRA unless there's a clear problem > > > and solution to be had. > > > > > > Personally, as a RM I try to gauge wether or not to abort an RC > > > depending on the specifics of the -1 votes cast. There's very little > > > chance I would sink an RC for a test I can't reproduce. Including a > > > release note is probably enough. I do tend to be more sympathetic to > > > compatibility concerns. I think the only way to get meaningful > > > assurance that the artifacts coming out of the project are what we as > > > a project support is to support folks voting according to the standard > > > they hold without requiring that any problems come with a solution. > > > but that doesn't work if a single -1 can block a release. As you > > > mention, that just becomes a hot potato of work without a volunteer. > > > > > > You've been doing an outsized share of the RM work for a long time > > > Andrew. As someone else who's done some of that work, I can empathize > > > that it's a grind without much noticeable appreciation. I don't have a > > > good answer for what it takes to get us through that discussion. If a > > > break from dealing with release management duties would help you stick > > > around longer contributing in other ways, e.g. evaluating RCs and > > > voting or reviewing features, then please go for it. It will > > > definitely be painful for the project's release cadence, but a regular > > > cadence of releases should be the responsibility of the entire PMC and > > > not one or two individuals. > > > > > > In the specific case of 1.4/1.5 RCs, I haven't caught up on the > > > current status yet but I'm happy to take a look and break off a > > > discussion thread for whatever is currently blocking things. > > > > > > On Thu, May 9, 2019 at 11:41 AM Andrew Purtell < > andrew.purt...@gmail.com> > > > wrote: > > > > > > > > .. a code base to the RM role. I don't believe vetos for RCs for > flaky > > > > tests should be considered valid reason to vote -1. I think we may be > > > > erring toward excessively maximal interpretation of compatibility > > > > guidelines in some cases. At any rate,
Re: I'm about to give up on RMing
Also, it is my observation that we are really only seeing difficulty attracting votes when RMs offer a 1.x release candidate. Maybe this implies the entire branch-1 forest should EOL. This will strand major users still on 1.x but it appears to be the consensus will of the community, if you interpret a lack of voting interest in that way. On Thu, May 9, 2019 at 10:32 AM Andrew Purtell wrote: > Sure I will concede treating -1s as vetos is a contributing factor, but I > think this is just a nod to reality. We have a hard enough time attracting > votes on a candidate as it is. When a -1 is cast, maybe I am insufficiently > optimistic, but I strongly suspect we won't get enough +1s to overcome it. > I think that is a realistic outlook. When someone comes to the thread and > sees a -1, will they bother? The -1 becomes a fait accompli, in my > estimation, so I treat it as a de facto veto. Perhaps this isn't the right > thing to be doing after all. Let me try your suggestion. Currently there is > a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, with a > closing date of tomorrow. It doesn't look promising I have to say but let's > let it continue. > > I would like to continue with RM duties. I enjoy it for the most part. It > is the voting that really kind of sucks now. It's hard to attract voters. > They make pronouncements without offering any volunteer effort in return. > That has become frustrating. > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > >> -1s on a release aren't a veto unless the RM treats them that way. >> Granted, given our current rate of votes they are very hard to >> overcome. I'm painfully aware of the time that goes into putting up an >> RC, and I don't think you should continue handling -1s as vetos. >> >> As a voter on RCs I try very hard to reflect on wether or not >> something can be addressed in future releases or via a release note. I >> usually don't preemptively file a JIRA unless there's a clear problem >> and solution to be had. >> >> Personally, as a RM I try to gauge wether or not to abort an RC >> depending on the specifics of the -1 votes cast. There's very little >> chance I would sink an RC for a test I can't reproduce. Including a >> release note is probably enough. I do tend to be more sympathetic to >> compatibility concerns. I think the only way to get meaningful >> assurance that the artifacts coming out of the project are what we as >> a project support is to support folks voting according to the standard >> they hold without requiring that any problems come with a solution. >> but that doesn't work if a single -1 can block a release. As you >> mention, that just becomes a hot potato of work without a volunteer. >> >> You've been doing an outsized share of the RM work for a long time >> Andrew. As someone else who's done some of that work, I can empathize >> that it's a grind without much noticeable appreciation. I don't have a >> good answer for what it takes to get us through that discussion. If a >> break from dealing with release management duties would help you stick >> around longer contributing in other ways, e.g. evaluating RCs and >> voting or reviewing features, then please go for it. It will >> definitely be painful for the project's release cadence, but a regular >> cadence of releases should be the responsibility of the entire PMC and >> not one or two individuals. >> >> In the specific case of 1.4/1.5 RCs, I haven't caught up on the >> current status yet but I'm happy to take a look and break off a >> discussion thread for whatever is currently blocking things. >> >> On Thu, May 9, 2019 at 11:41 AM Andrew Purtell >> wrote: >> > >> > .. a code base to the RM role. I don't believe vetos for RCs for flaky >> > tests should be considered valid reason to vote -1. I think we may be >> > erring toward excessively maximal interpretation of compatibility >> > guidelines in some cases. At any rate, where does the responsibility lie >> > for fixing the issues? And do voters consider the personal cost to the >> RM >> > in terms of time and attention in rolling the RC when deciding to vote >> -1? >> > The -1 vote has a cost. It requires the RM to restart the RC. My >> impression >> > is this isn't a consideration. >> > >> > >> > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > > >> > wrote: >> > >> > > /cc private@ >> > > >> > > I believe you are pushing your collective burden as a group of >> committers >> > > sharing responsiblity to >> > > >> > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell < >> andrew.purt...@gmail.com> >> > > wrote: >> > > >> > >> My experience with the last four RC attempts I have made has been >> just a >> > >> constant stream of vetos for flaky tests which I can't reproduce (at >> least >> > >> not with the usual 10 iterations of the suite) and possibly pedantic >> > >> compatability report interpretations with no patches to help and in >> some >> > >> cases not even JIRAs filed to follow up on specifying the
Re: I'm about to give up on RMing
Personally I don't think we have enough community release voting to support having closing dates on votes. This was definitely the case on 1.2 releases. IIRC it was also true fo the last 1.3 release. I think you're already using the "I would like to close this around XXX" phrasing, but just in case I'm mistaken I figure I should call it out. On Thu, May 9, 2019 at 12:32 PM Andrew Purtell wrote: > > Sure I will concede treating -1s as vetos is a contributing factor, but I > think this is just a nod to reality. We have a hard enough time attracting > votes on a candidate as it is. When a -1 is cast, maybe I am insufficiently > optimistic, but I strongly suspect we won't get enough +1s to overcome it. > I think that is a realistic outlook. When someone comes to the thread and > sees a -1, will they bother? The -1 becomes a fait accompli, in my > estimation, so I treat it as a de facto veto. Perhaps this isn't the right > thing to be doing after all. Let me try your suggestion. Currently there is > a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, with a > closing date of tomorrow. It doesn't look promising I have to say but let's > let it continue. > > I would like to continue with RM duties. I enjoy it for the most part. It > is the voting that really kind of sucks now. It's hard to attract voters. > They make pronouncements without offering any volunteer effort in return. > That has become frustrating. > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > > > -1s on a release aren't a veto unless the RM treats them that way. > > Granted, given our current rate of votes they are very hard to > > overcome. I'm painfully aware of the time that goes into putting up an > > RC, and I don't think you should continue handling -1s as vetos. > > > > As a voter on RCs I try very hard to reflect on wether or not > > something can be addressed in future releases or via a release note. I > > usually don't preemptively file a JIRA unless there's a clear problem > > and solution to be had. > > > > Personally, as a RM I try to gauge wether or not to abort an RC > > depending on the specifics of the -1 votes cast. There's very little > > chance I would sink an RC for a test I can't reproduce. Including a > > release note is probably enough. I do tend to be more sympathetic to > > compatibility concerns. I think the only way to get meaningful > > assurance that the artifacts coming out of the project are what we as > > a project support is to support folks voting according to the standard > > they hold without requiring that any problems come with a solution. > > but that doesn't work if a single -1 can block a release. As you > > mention, that just becomes a hot potato of work without a volunteer. > > > > You've been doing an outsized share of the RM work for a long time > > Andrew. As someone else who's done some of that work, I can empathize > > that it's a grind without much noticeable appreciation. I don't have a > > good answer for what it takes to get us through that discussion. If a > > break from dealing with release management duties would help you stick > > around longer contributing in other ways, e.g. evaluating RCs and > > voting or reviewing features, then please go for it. It will > > definitely be painful for the project's release cadence, but a regular > > cadence of releases should be the responsibility of the entire PMC and > > not one or two individuals. > > > > In the specific case of 1.4/1.5 RCs, I haven't caught up on the > > current status yet but I'm happy to take a look and break off a > > discussion thread for whatever is currently blocking things. > > > > On Thu, May 9, 2019 at 11:41 AM Andrew Purtell > > wrote: > > > > > > .. a code base to the RM role. I don't believe vetos for RCs for flaky > > > tests should be considered valid reason to vote -1. I think we may be > > > erring toward excessively maximal interpretation of compatibility > > > guidelines in some cases. At any rate, where does the responsibility lie > > > for fixing the issues? And do voters consider the personal cost to the RM > > > in terms of time and attention in rolling the RC when deciding to vote > > -1? > > > The -1 vote has a cost. It requires the RM to restart the RC. My > > impression > > > is this isn't a consideration. > > > > > > > > > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > > > wrote: > > > > > > > /cc private@ > > > > > > > > I believe you are pushing your collective burden as a group of > > committers > > > > sharing responsiblity to > > > > > > > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell < > > andrew.purt...@gmail.com> > > > > wrote: > > > > > > > >> My experience with the last four RC attempts I have made has been > > just a > > > >> constant stream of vetos for flaky tests which I can't reproduce (at > > least > > > >> not with the usual 10 iterations of the suite) and possibly pedantic > > > >> compatability report interpretations with no patches to help and in > >
Re: I'm about to give up on RMing
Sure I will concede treating -1s as vetos is a contributing factor, but I think this is just a nod to reality. We have a hard enough time attracting votes on a candidate as it is. When a -1 is cast, maybe I am insufficiently optimistic, but I strongly suspect we won't get enough +1s to overcome it. I think that is a realistic outlook. When someone comes to the thread and sees a -1, will they bother? The -1 becomes a fait accompli, in my estimation, so I treat it as a de facto veto. Perhaps this isn't the right thing to be doing after all. Let me try your suggestion. Currently there is a vote in progress on 1.4.10RC0 with one -1 vote and no other votes, with a closing date of tomorrow. It doesn't look promising I have to say but let's let it continue. I would like to continue with RM duties. I enjoy it for the most part. It is the voting that really kind of sucks now. It's hard to attract voters. They make pronouncements without offering any volunteer effort in return. That has become frustrating. On Thu, May 9, 2019 at 10:26 AM Sean Busbey wrote: > -1s on a release aren't a veto unless the RM treats them that way. > Granted, given our current rate of votes they are very hard to > overcome. I'm painfully aware of the time that goes into putting up an > RC, and I don't think you should continue handling -1s as vetos. > > As a voter on RCs I try very hard to reflect on wether or not > something can be addressed in future releases or via a release note. I > usually don't preemptively file a JIRA unless there's a clear problem > and solution to be had. > > Personally, as a RM I try to gauge wether or not to abort an RC > depending on the specifics of the -1 votes cast. There's very little > chance I would sink an RC for a test I can't reproduce. Including a > release note is probably enough. I do tend to be more sympathetic to > compatibility concerns. I think the only way to get meaningful > assurance that the artifacts coming out of the project are what we as > a project support is to support folks voting according to the standard > they hold without requiring that any problems come with a solution. > but that doesn't work if a single -1 can block a release. As you > mention, that just becomes a hot potato of work without a volunteer. > > You've been doing an outsized share of the RM work for a long time > Andrew. As someone else who's done some of that work, I can empathize > that it's a grind without much noticeable appreciation. I don't have a > good answer for what it takes to get us through that discussion. If a > break from dealing with release management duties would help you stick > around longer contributing in other ways, e.g. evaluating RCs and > voting or reviewing features, then please go for it. It will > definitely be painful for the project's release cadence, but a regular > cadence of releases should be the responsibility of the entire PMC and > not one or two individuals. > > In the specific case of 1.4/1.5 RCs, I haven't caught up on the > current status yet but I'm happy to take a look and break off a > discussion thread for whatever is currently blocking things. > > On Thu, May 9, 2019 at 11:41 AM Andrew Purtell > wrote: > > > > .. a code base to the RM role. I don't believe vetos for RCs for flaky > > tests should be considered valid reason to vote -1. I think we may be > > erring toward excessively maximal interpretation of compatibility > > guidelines in some cases. At any rate, where does the responsibility lie > > for fixing the issues? And do voters consider the personal cost to the RM > > in terms of time and attention in rolling the RC when deciding to vote > -1? > > The -1 vote has a cost. It requires the RM to restart the RC. My > impression > > is this isn't a consideration. > > > > > > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > > wrote: > > > > > /cc private@ > > > > > > I believe you are pushing your collective burden as a group of > committers > > > sharing responsiblity to > > > > > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell < > andrew.purt...@gmail.com> > > > wrote: > > > > > >> My experience with the last four RC attempts I have made has been > just a > > >> constant stream of vetos for flaky tests which I can't reproduce (at > least > > >> not with the usual 10 iterations of the suite) and possibly pedantic > > >> compatability report interpretations with no patches to help and in > some > > >> cases not even JIRAs filed to follow up on specifying the complaint. > Life > > >> is too short to waste time and effort like this. > > >> > > >> > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > >- A23, Crosstalk > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the
Re: I'm about to give up on RMing
-1s on a release aren't a veto unless the RM treats them that way. Granted, given our current rate of votes they are very hard to overcome. I'm painfully aware of the time that goes into putting up an RC, and I don't think you should continue handling -1s as vetos. As a voter on RCs I try very hard to reflect on wether or not something can be addressed in future releases or via a release note. I usually don't preemptively file a JIRA unless there's a clear problem and solution to be had. Personally, as a RM I try to gauge wether or not to abort an RC depending on the specifics of the -1 votes cast. There's very little chance I would sink an RC for a test I can't reproduce. Including a release note is probably enough. I do tend to be more sympathetic to compatibility concerns. I think the only way to get meaningful assurance that the artifacts coming out of the project are what we as a project support is to support folks voting according to the standard they hold without requiring that any problems come with a solution. but that doesn't work if a single -1 can block a release. As you mention, that just becomes a hot potato of work without a volunteer. You've been doing an outsized share of the RM work for a long time Andrew. As someone else who's done some of that work, I can empathize that it's a grind without much noticeable appreciation. I don't have a good answer for what it takes to get us through that discussion. If a break from dealing with release management duties would help you stick around longer contributing in other ways, e.g. evaluating RCs and voting or reviewing features, then please go for it. It will definitely be painful for the project's release cadence, but a regular cadence of releases should be the responsibility of the entire PMC and not one or two individuals. In the specific case of 1.4/1.5 RCs, I haven't caught up on the current status yet but I'm happy to take a look and break off a discussion thread for whatever is currently blocking things. On Thu, May 9, 2019 at 11:41 AM Andrew Purtell wrote: > > .. a code base to the RM role. I don't believe vetos for RCs for flaky > tests should be considered valid reason to vote -1. I think we may be > erring toward excessively maximal interpretation of compatibility > guidelines in some cases. At any rate, where does the responsibility lie > for fixing the issues? And do voters consider the personal cost to the RM > in terms of time and attention in rolling the RC when deciding to vote -1? > The -1 vote has a cost. It requires the RM to restart the RC. My impression > is this isn't a consideration. > > > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > wrote: > > > /cc private@ > > > > I believe you are pushing your collective burden as a group of committers > > sharing responsiblity to > > > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell > > wrote: > > > >> My experience with the last four RC attempts I have made has been just a > >> constant stream of vetos for flaky tests which I can't reproduce (at least > >> not with the usual 10 iterations of the suite) and possibly pedantic > >> compatability report interpretations with no patches to help and in some > >> cases not even JIRAs filed to follow up on specifying the complaint. Life > >> is too short to waste time and effort like this. > >> > >> > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk
Re: I'm about to give up on RMing
Something like that would be an improvement. I think my frustration stems from a sense the burden isn't equitably shared. It also relates to what I do as a RM which isn't policy per se. First, I run the unit suite several times in a loop. This is scripted, but it takes time to complete and review the results, and investigating failures and filing issues takes time too. Then I will do the same basic checks a voter will take. Then I might run LTT or ITBLL, which is hands on and takes more time. So far the volunteer time spent seems perfectly reasonable and not onerous. This is not my complaint. When there is a veto, is the expectation the RM will follow up and fix the problem? If it is a flaky test, that cannot be locally reproduced, this is an additional mandate that could be costly in terms of time. As a voter, when you cast a veto because of a compatibility issue have you really considered if it might be allowed - our guidelines are just guidelines, and are fuzzy by nature? Because as RM I looked at that report too and thought it ambiguous enough to continue. The committer allowed it implicitly by the commit. In some cases as RM I have reopened JIRAs for compatibility problems. The recent 1.4.10RC0 is case in point. After back and forth with the committer an incompatible change of low severity was allowed on a Public interface. The voter should take this kind of action. At the least we should have a JIRA reopened or filed for discussion of the problem. What should not be considered valid, in my opinion, is a pedantic veto that only mentions the compatibility report as reason. This is not helpful. Guidelines, and fuzzy, if you recall. In general for test or compatibility issues, is the expectation the RM will fix it? That is a big assumption about the RM's personal circumstances, wouldn't you think? Or interest in volunteering? Volunteer resources are precious. We need to be mindful of the tradeoff here. It also applies in code review. I think generally we strike the right balance between quality assurance and considerations to volunteer time, but in some recent RC votes I have gotten the impression not. No JIRAs for veto reasons. No proactive debug of unit test failure. No patches. Hence a sense the burden for maintaining the code isn't as equitably shared as it should be. A policy as suggested, like a consensus that vetos should only be cast if the issue deserves a JIRA with Critical would certainly be one way to shift the balance. I don't think something like that is necessary. Smaller steps as simple as giving the RM the courtesy of filing JIRAs that explain the veto and describe steps to fix would be enough. This would shift the burden for test failures onto the observers, who are in the best position to understand the failure because they are the ones seeing it. It also shifts burden on disagreements over compatibility report results. A veto for a compatibility issue is a priori a disagreement between the voter and the committer, and the voter and the RM. Proactive effort and remedy on the part of the voter should be implied by this. Thank you for your consideration. For your consideration. On Thu, May 9, 2019 at 9:52 AM Artem Ervits wrote: > should -1 only apply with a valid critical Jira in hand? > > On Thu, May 9, 2019 at 12:41 PM Andrew Purtell > wrote: > > > .. a code base to the RM role. I don't believe vetos for RCs for flaky > > tests should be considered valid reason to vote -1. I think we may be > > erring toward excessively maximal interpretation of compatibility > > guidelines in some cases. At any rate, where does the responsibility lie > > for fixing the issues? And do voters consider the personal cost to the RM > > in terms of time and attention in rolling the RC when deciding to vote > -1? > > The -1 vote has a cost. It requires the RM to restart the RC. My > impression > > is this isn't a consideration. > > > > > > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > > wrote: > > > > > /cc private@ > > > > > > I believe you are pushing your collective burden as a group of > committers > > > sharing responsiblity to > > > > > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell < > andrew.purt...@gmail.com> > > > wrote: > > > > > >> My experience with the last four RC attempts I have made has been > just a > > >> constant stream of vetos for flaky tests which I can't reproduce (at > > least > > >> not with the usual 10 iterations of the suite) and possibly pedantic > > >> compatability report interpretations with no patches to help and in > some > > >> cases not even JIRAs filed to follow up on specifying the complaint. > > Life > > >> is too short to waste time and effort like this. > > >> > > >> > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > >- A23, Crosstalk > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning
[jira] [Created] (HBASE-22388) Document new completebulkload invocation in 3.x when LoadIncrementalHFiles is removed
Artem Ervits created HBASE-22388:
Summary: Document new completebulkload invocation in 3.x when
LoadIncrementalHFiles is removed
Key: HBASE-22388
URL: https://issues.apache.org/jira/browse/HBASE-22388
Project: HBase
Issue Type: Bug
Components: documentation
Affects Versions: 2.2.0
Reporter: Artem Ervits
Assignee: Artem Ervits
as per [~psomogyi] LoadIncrementalHFiles is deprecated in 2.2 and removed in
3.0. Document BulkLoadHFilesTool invocation. for example
{code:java}
hbase org.apache.hadoop.hbase.tool.BulkLoadHFilesTool completebulkload{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: I'm about to give up on RMing
should -1 only apply with a valid critical Jira in hand? On Thu, May 9, 2019 at 12:41 PM Andrew Purtell wrote: > .. a code base to the RM role. I don't believe vetos for RCs for flaky > tests should be considered valid reason to vote -1. I think we may be > erring toward excessively maximal interpretation of compatibility > guidelines in some cases. At any rate, where does the responsibility lie > for fixing the issues? And do voters consider the personal cost to the RM > in terms of time and attention in rolling the RC when deciding to vote -1? > The -1 vote has a cost. It requires the RM to restart the RC. My impression > is this isn't a consideration. > > > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > wrote: > > > /cc private@ > > > > I believe you are pushing your collective burden as a group of committers > > sharing responsiblity to > > > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell > > wrote: > > > >> My experience with the last four RC attempts I have made has been just a > >> constant stream of vetos for flaky tests which I can't reproduce (at > least > >> not with the usual 10 iterations of the suite) and possibly pedantic > >> compatability report interpretations with no patches to help and in some > >> cases not even JIRAs filed to follow up on specifying the complaint. > Life > >> is too short to waste time and effort like this. > >> > >> > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
Re: I'm about to give up on RMing
.. a code base to the RM role. I don't believe vetos for RCs for flaky tests should be considered valid reason to vote -1. I think we may be erring toward excessively maximal interpretation of compatibility guidelines in some cases. At any rate, where does the responsibility lie for fixing the issues? And do voters consider the personal cost to the RM in terms of time and attention in rolling the RC when deciding to vote -1? The -1 vote has a cost. It requires the RM to restart the RC. My impression is this isn't a consideration. On Thu, May 9, 2019 at 9:37 AM Andrew Purtell wrote: > /cc private@ > > I believe you are pushing your collective burden as a group of committers > sharing responsiblity to > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell > wrote: > >> My experience with the last four RC attempts I have made has been just a >> constant stream of vetos for flaky tests which I can't reproduce (at least >> not with the usual 10 iterations of the suite) and possibly pedantic >> compatability report interpretations with no patches to help and in some >> cases not even JIRAs filed to follow up on specifying the complaint. Life >> is too short to waste time and effort like this. >> >> > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [VOTE] The first HBase 1.4.10 release candidate (RC0) is available
Are you referring to the changes I called out in HBASE-22215 or something else? If HBASE-22215 please do us the courtesy of reopening it with your objection, because the change was given due consideration there already. Additive changes to LP classes are allowed, I believe, but you will need to be more specific. I can only guess what you are looking at. Currently this veto is not valid because it does not indicate what the actual problem is. Please file a JIRA with your instructions to remedy the problem. At the very least list the items you feel are at issue. > On May 9, 2019, at 2:53 AM, Peter Somogyi wrote: > > -1 > > Compatibility report shows removed methods and changed constructor > signature for a IA.Public interface. There are also a couple of changes for > IA.LP classes. > > Also checked: > Checksum, signature OK > Rat check OK > Unit tests OK > Simple shell commands OK > LTT 1M rows OK > Master, RS UI OK > >> On Sat, May 4, 2019 at 3:07 AM Andrew Purtell wrote: >> >> Pardon me, there is a typo on the close date for the vote. I would like to >> close the vote by or on May 10, 2019. The tenth, not the nineteenth, thank >> you. >> >> >>> On Fri, May 3, 2019 at 6:04 PM Andrew Purtell wrote: >>> >>> The first HBase 1.4.10 release candidate (RC0) is available for download >>> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/ and >>> Maven artifacts are available in the temporary repository >>> https://repository.apache.org/content/repositories/orgapachehbase-1310 . >>> >>> The git tag corresponding to the candidate is '1.4.10RC0' (8a597e477e). >>> >>> A detailed source and binary compatibility report for this release is >>> available for your review at >>> >> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/compat-check-report.html >>> . There are no reported compatibility issues of concern. The changes to >>> Public annotated class MultiRowRangeFilter are reported as low impact by >>> the compatibility checker tool and were discussed and allowed on >>> . >>> >>> A list of the 57 issues resolved in this release can be found at >>> https://s.apache.org/7gSD . >>> >>> Please try out the candidate and vote +1/0/-1. >>> >>> The vote will be open for at least 72 hours. Unless objection I will try >>> to close it Friday May 19, 2019 if we have sufficient votes. >>> >>> Prior to making this announcement I made the following preflight checks: >>> >>>RAT check passes (7u80) >>>Unit test suite passes 5/5 (7u80, 8u172) >>>LTT load 100M rows with 100% verification and 20% updates (8u181) >>> >>> >>> -- >>> Best regards, >>> Andrew >>> >>> >> >> -- >> Best regards, >> Andrew >> >> Words like orphans lost among the crosstalk, meaning torn from truth's >> decrepit hands >> - A23, Crosstalk >>
Re: I'm about to give up on RMing
/cc private@ I believe you are pushing your collective burden as a group of committers sharing responsiblity to On Thu, May 9, 2019 at 9:33 AM Andrew Purtell wrote: > My experience with the last four RC attempts I have made has been just a > constant stream of vetos for flaky tests which I can't reproduce (at least > not with the usual 10 iterations of the suite) and possibly pedantic > compatability report interpretations with no patches to help and in some > cases not even JIRAs filed to follow up on specifying the complaint. Life > is too short to waste time and effort like this. > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
I'm about to give up on RMing
My experience with the last four RC attempts I have made has been just a constant stream of vetos for flaky tests which I can't reproduce (at least not with the usual 10 iterations of the suite) and possibly pedantic compatability report interpretations with no patches to help and in some cases not even JIRAs filed to follow up on specifying the complaint. Life is too short to waste time and effort like this.
HBase Compressed Data in ZNodes
Hello Team, ZooKeeper recently added a feature to enable compression for values stored in ZNodes when the nodes are persisted to disk. Obviously this feature is less interesting if the data written into the ZNodes is already compressed. https://issues.apache.org/jira/browse/ZOOKEEPER-3179 With that said, I know HBase is a big consumer of ZNode services. Does HBase store any sizable information in ZNodes? If so, is this data compressed? Would HBase installations gain from this new feature? Thanks!
[jira] [Resolved] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics on object stores
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-22149. - Resolution: Fixed Fix Version/s: hbase-filesystem-1.0.0-alpha1 Release Note: Initial implementation of the hbase-oss module. Defines a wrapper FileSystem implementation of Apache Hadoop's FileSystem interface that bridges the gap between Apache HBase, which assumes that many operations are atomic, and object-store implementations of FileSystem (such as s3a) which inherently cannot provide atomic semantics to those operations natively. The implementation can be used e.g. with the s3a filesystem by using a root fs like `s3a://bucket/` and defining * `fs.s3a.impl` set to `org.apache.hadoop.hbase.oss.HBaseObjectStoreSemantics` * `fs.hboss.fs.s3a.impl` set to `org.apache.hadoop.fs.s3a.S3AFileSystem` more details in the module's README.md NOTE: This module is labeled with an ALPHA version. It is not considered production ready and makes no promises about compatibility between versions. Initial implementation merged to the hbase-filesystem repository. Thanks [~mackrorysd] and [~wchevreuil] for the work so far! If anyone wants to see more/different details in the release note please feel free to edit or suggest. > HBOSS: A FileSystem implementation to provide HBase's required semantics on > object stores > - > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Fix For: hbase-filesystem-1.0.0-alpha1 > > Attachments: HBASE-22149-hadoop.patch, HBASE-22149-hbase-2.patch, > HBASE-22149-hbase-3.patch, HBASE-22149-hbase-4.patch, > HBASE-22149-hbase-5.patch, HBASE-22149-hbase-filesystem-1.patch, > HBASE-22149-hbase-filesystem-1.patch, HBASE-22149-hbase.patch > > > (Have been using the name HBOSS for HBase / Object Store Semantics) > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This
Re: [ANNOUNCE] Please welcome Jan Hentschel to the Apache HBase PMC
Congratulations Jan! On Thu, May 9, 2019 at 12:07 PM Lars Francke wrote: > Congratulations Jan and especially thank you for your work on the > deprecations > > On Wed, May 8, 2019 at 11:37 PM Sean Busbey wrote: > > > On behalf of the Apache HBase PMC I am pleased to announce that Jan > > Hentschel has accepted our invitation to become a PMC member on the > > HBase project. We appreciate Jan stepping up to take more > > responsibility in the HBase project. > > > > Please join me in welcoming Jan to the HBase PMC! > > > > > > > > As a reminder, if anyone would like to nominate another person as a > > committer or PMC member, even if you are not currently a committer or > > PMC member, you can always drop a note to priv...@hbase.apache.org to > > let us know. > > > > -busbey > > >
[jira] [Resolved] (HBASE-22358) Change rubocop configuration for method length
[ https://issues.apache.org/jira/browse/HBASE-22358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel resolved HBASE-22358. --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.4.11 1.3.5 2.2.1 2.1.5 2.0.6 2.3.0 1.5.0 3.0.0 Release Note: The rubocop definition for the maximum method length was set to 75. > Change rubocop configuration for method length > -- > > Key: HBASE-22358 > URL: https://issues.apache.org/jira/browse/HBASE-22358 > Project: HBase > Issue Type: Improvement > Components: community, shell >Reporter: Jan Hentschel >Assignee: Murtaza Hassan >Priority: Minor > Labels: beginner, beginners > Fix For: 3.0.0, 1.5.0, 2.3.0, 2.0.6, 2.1.5, 2.2.1, 1.3.5, 1.4.11 > > > rubocop currently uses a maximum method length for the Ruby code of 10, which > is way too restrictive. In Checkstyle we're using 150 lines per method. Don't > know if it needs to be that much, but something between 50 and 75 seems to be > more realistic, especially for test cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [ANNOUNCE] Please welcome Jan Hentschel to the Apache HBase PMC
Congratulations Jan and especially thank you for your work on the deprecations On Wed, May 8, 2019 at 11:37 PM Sean Busbey wrote: > On behalf of the Apache HBase PMC I am pleased to announce that Jan > Hentschel has accepted our invitation to become a PMC member on the > HBase project. We appreciate Jan stepping up to take more > responsibility in the HBase project. > > Please join me in welcoming Jan to the HBase PMC! > > > > As a reminder, if anyone would like to nominate another person as a > committer or PMC member, even if you are not currently a committer or > PMC member, you can always drop a note to priv...@hbase.apache.org to > let us know. > > -busbey >
[jira] [Reopened] (HBASE-21800) RegionServer aborted due to NPE from MetaTableMetrics coprocessor
[
https://issues.apache.org/jira/browse/HBASE-21800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi reopened HBASE-21800:
---
> RegionServer aborted due to NPE from MetaTableMetrics coprocessor
> -
>
> Key: HBASE-21800
> URL: https://issues.apache.org/jira/browse/HBASE-21800
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, meta, metrics, Operability
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Critical
> Labels: Meta
> Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.10, 2.3.0
>
> Attachments: hbase-21800.branch-1.001.patch,
> hbase-21800.branch-1.002.patch, hbase-21800.branch-1.003.patch,
> hbase-21800.branch-1.004.patch, hbase-21800.master.001.patch,
> hbase-21800.master.002.patch, hbase-21800.master.003.patch
>
>
> I was just playing around the code, trying to capture "Top k" table metrics
> from MetaMetrics, when I bumped into this issue. Though currently we are not
> capturing "Top K" table metrics, but we can encounter this issue because of
> the "Top k Clients" that is implemented using the LossyAlgo.
>
> RegionServer gets aborted due to a NPE from MetaTableMetrics coprocessor. The
> log looks somewhat like this:
> {code:java}
> 2019-01-28 23:31:10,311 ERROR
> [RpcServer.priority.FPBQ.Fifo.handler=19,queue=1,port=16020]
> coprocessor.CoprocessorHost: The coprocessor
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics threw
> java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.markMeterIfPresent(MetaTableMetrics.java:123)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.tableMetricRegisterAndMark2(MetaTableMetrics.java:233)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.preGetOp(MetaTableMetrics.java:82)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:840)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:551)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:625)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preGet(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2608)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2547)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41998)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:413)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> 2019-01-28 23:31:10,314 ERROR
> [RpcServer.priority.FPBQ.Fifo.handler=19,queue=1,port=16020]
> regionserver.HRegionServer: * ABORTING region server
> 10.0.0.24,16020,1548747043814: The coprocessor
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics threw
> java.lang.NullPointerException *
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.markMeterIfPresent(MetaTableMetrics.java:123)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.tableMetricRegisterAndMark2(MetaTableMetrics.java:233)
> at
> org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.preGetOp(MetaTableMetrics.java:82)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:840)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:551)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:625)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preGet(RegionCoprocessorHost.java:837)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2608)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2547)
> at
>
[jira] [Reopened] (HBASE-21991) Fix MetaMetrics issues - [Race condition, Faulty remove logic], few improvements
[ https://issues.apache.org/jira/browse/HBASE-21991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi reopened HBASE-21991: --- > Fix MetaMetrics issues - [Race condition, Faulty remove logic], few > improvements > > > Key: HBASE-21991 > URL: https://issues.apache.org/jira/browse/HBASE-21991 > Project: HBase > Issue Type: Bug > Components: Coprocessors, metrics >Reporter: Sakthi >Assignee: Sakthi >Priority: Major > Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.10, 2.3.0 > > Attachments: hbase-21991.branch-1.001.patch, > hbase-21991.branch-1.002.patch, hbase-21991.master.001.patch, > hbase-21991.master.002.patch, hbase-21991.master.003.patch, > hbase-21991.master.004.patch, hbase-21991.master.005.patch, > hbase-21991.master.006.patch > > > Here is a list of the issues related to the MetaMetrics implementation: > +*Bugs*+: > # [_Lossy counting for top-k_] *Faulty remove logic of non-eligible meters*: > Under certain conditions, we might end up storing/exposing all the meters > rather than top-k-ish > # MetaMetrics can throw NPE resulting in aborting of the RS because of a > *Race Condition*. > +*Improvements*+: > # With high number of regions in the cluster, exposure of metrics for each > region blows up the JMX from ~140 Kbs to 100+ Mbs depending on the number of > regions. It's better to use *lossy counting to maintain top-k for region > metrics* as well. > # As the lossy meters do not represent actual counts, I think, it'll be > better to *rename the meters to include "lossy" in the name*. It would be > more informative while monitoring the metrics and there would be less > confusion regarding actual counts to lossy counts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] The first HBase 1.4.10 release candidate (RC0) is available
-1 Compatibility report shows removed methods and changed constructor signature for a IA.Public interface. There are also a couple of changes for IA.LP classes. Also checked: Checksum, signature OK Rat check OK Unit tests OK Simple shell commands OK LTT 1M rows OK Master, RS UI OK On Sat, May 4, 2019 at 3:07 AM Andrew Purtell wrote: > Pardon me, there is a typo on the close date for the vote. I would like to > close the vote by or on May 10, 2019. The tenth, not the nineteenth, thank > you. > > > On Fri, May 3, 2019 at 6:04 PM Andrew Purtell wrote: > > > The first HBase 1.4.10 release candidate (RC0) is available for download > > at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/ and > > Maven artifacts are available in the temporary repository > > https://repository.apache.org/content/repositories/orgapachehbase-1310 . > > > > The git tag corresponding to the candidate is '1.4.10RC0' (8a597e477e). > > > > A detailed source and binary compatibility report for this release is > > available for your review at > > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC0/compat-check-report.html > > . There are no reported compatibility issues of concern. The changes to > > Public annotated class MultiRowRangeFilter are reported as low impact by > > the compatibility checker tool and were discussed and allowed on > > HBASE-22215. > > > > A list of the 57 issues resolved in this release can be found at > > https://s.apache.org/7gSD . > > > > Please try out the candidate and vote +1/0/-1. > > > > The vote will be open for at least 72 hours. Unless objection I will try > > to close it Friday May 19, 2019 if we have sufficient votes. > > > > Prior to making this announcement I made the following preflight checks: > > > > RAT check passes (7u80) > > Unit test suite passes 5/5 (7u80, 8u172) > > LTT load 100M rows with 100% verification and 20% updates (8u181) > > > > > > -- > > Best regards, > > Andrew > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
[jira] [Created] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly
Zheng Hu created HBASE-22387: Summary: Evaluate the get/scan performance after reading HFile block into offheap directly Key: HBASE-22387 URL: https://issues.apache.org/jira/browse/HBASE-22387 Project: HBase Issue Type: Sub-task Reporter: Zheng Hu Assignee: Zheng Hu Now, all sub-tasks has been resolved now (except the HBASE-21946 because of the hadoop dependency problem), will provide some performance benckmarks to show the latency improvement. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
