[jira] [Created] (HBASE-21465) Retry on reportRegionStateTransition can lead to unexpected errors
Duo Zhang created HBASE-21465: - Summary: Retry on reportRegionStateTransition can lead to unexpected errors Key: HBASE-21465 URL: https://issues.apache.org/jira/browse/HBASE-21465 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang Fix For: 3.0.0, 2.2.0 It is possible that the reportRegionStateTransition method is succeeded at master side, but before returning the the region server, the rpc connection is broken, or the master restarts. So next when the region server try again,we will find that the state for the region and the TRSP is not correct, and can lead to a RS abort or something even worse. We should be able to determine whether a reportRegionStateTransition call is just a retry and has already been succeeded, and just ignore it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21466) WALProcedureStore uses wrong FileSystem if wal.dir is on different FileSystem as rootdir
Ted Yu created HBASE-21466:
--
Summary: WALProcedureStore uses wrong FileSystem if wal.dir is on
different FileSystem as rootdir
Key: HBASE-21466
URL: https://issues.apache.org/jira/browse/HBASE-21466
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
In WALProcedureStore ctor , the fs field is initialized this way:
{code}
this.fs = walDir.getFileSystem(conf);
{code}
However, when wal.dir is on different FileSystem as rootdir, the above would
return wrong FileSystem.
In the modified TestMasterProcedureEvents, without fix, the master wouldn't
initialize.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] Release cadence for HBase 2.y
Agree w/ Duo that the 2.x releases have been gated on stability watersheds rather than features. What else do we need to add to HBCK2 Duo (apart from a release)? Related, I was going to work on a 2.0.3 release. It has been a while and a bunch of good stability work has made it into branch-2.0. Thereafter though, I was going to let branch-2.0 go unless demand -- Allan Yang? -- and switch instead to helping out on branch-2.2. S On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) wrote: > I think for the 2.x release the problem is that we are still busy on making > the code stable, or speak more clearly, to make the procedure v2 framework > stable... And another big problem is lacking of HBCK2 support. These things > are all big issues which prevent people to upgrade to 2.x. > > Once these things are done, I think a monthly release will not be a big > problem to the RMs. Just simply run an ITBLL(for now it is not easy to get > a successful run and then we need to find out why...), and then the > make_rc.sh can not everything for you... > > Sean Busbey 于2018年11月9日周五 上午9:45写道： > > > I think it just shifts the RM burden, no? Like instead of watching e.g. > > branch-2.2 I instead need to watch branch-2. > > > > On Thu, Nov 8, 2018, 17:28 Josh Elser > > > > I think what I'd be concerned about WRT time-based releases is the > > > burden on RM to keep the branch in a good state. Perhaps we need to not > > > push that onto an RM and do better about sharing that load (looking in > > > the mirror). > > > > > > However, I do like time-based releases as a means to avoid "hurt > > > feelings" (e.g. the personal ties of a developer to a feature. "The > > > release goes out on /yy/xx, this feature is not yet ready, can go > > > out one month later.." etc) > > > > > > On 11/7/18 2:31 PM, Sean Busbey wrote: > > > > Hi folks! > > > > > > > > Some time ago we talked about trying to get back on track for a more > > > > regular cadence of minor releases rather than maintenance releases > > > > (like how we did back pre-1.0). That never quite worked out for the > > > > HBase 1.y line, but is still something we could make happen for HBase > > > > 2. > > > > > > > > We're coming up on 4 months since the 2.1 release line started. ATM > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in any > > > > 2.1.z version[1]. > > > > > > > > The main argument against starting to do a 2.2.0 release is that > > > > nothing springs out of that list as a "feature" that would entice > > > > users to upgrade. Waiting for these kinds of selling points to drive > a > > > > release is commonly referred to as "feature based releases." I think > > > > it would be fair to characterize the HBase 2.0 release as feature > > > > based centered on AMv2. > > > > > > > > An alternative to feature based releases is date based releases where > > > > we decide that e.g. we'll have a minor release each month regardless > > > > of how much is included in it. This is sometimes also called "train > > > > releases" as an analogy to how trains leave a station on a set > > > > schedule without regard to which individual passengers are ready. > Just > > > > as you'd catch the next scheduled train if you miss-timed your > > > > arrival, fixes or features that aren't ready just go in the next > > > > regular release. > > > > > > > > Personally, I really like the idea of doing date based releases for > > > > minor releases with maintenance releases essentially only happening > on > > > > whatever our "stable" designator points at. It would mean those who > > > > don't want the risk and benefits of our current release-ready work > > > > could stay on a defined path while we could move away from > maintaining > > > > a ton of branches, some of which don't even see releases (currently > ~3 > > > > that are > 3 months since a release). If some folks had a specific > > > > need for a different minor release line and were willing to do the > > > > backport and RM work for that line, they'd of course be free to do > so. > > > > > > > > I know there are some current unknowns around 2.2 specifically. I > > > > think stack mentioned to me that there's an upgrade consideration > that > > > > we need to hammer out since I don't see anything specific to 2.2 in > > > > the "Upgrade Paths" section of the ref guide right now. While I am > > > > interested in getting 2.2 going specifically, I'd like to make sure > we > > > > address the general topic of regularly getting new minor releases > out. > > > > If we already had an expectation that there'd be a minor release > every > > > > e.g. month or 2 months then I expect whatever upgrade issue would > have > > > > been addressed as a part of the change that caused it going in. > > > > > > > > What do folks think? > > > > > > > > [1]: > > > > https://s.apache.org/AAma > > > > > > > > > >
Re: [DISCUSS] Release cadence for HBase 2.y
But, since that some users may already have their production system on HBase-2.0.x, maybe we should consider their feelings, they are the 'first movers'. If we retire branch-2.0 so quickly, IIRC, the branch-2.0 will be the shortest life branch ever. I think it will hurt the feeling of those 'first movers'. If we take this into count, then I think maybe we should keep branch-2.0 at least one year. If the community is shorthanded, I volunteer to take responsible to decide/backport/release branch-2.0 since I was working on this branch most recently. Anyway, this thread is about releasing HBase2.2.x, I will vote a +1 for it, as for HBase-2.0.x, we can discuss later. Best Regards Allan Yang Allan Yang 于2018年11月12日周一 上午10:12写道： > Stack, are you suggest about retiring branch-2.0? I think it is OK, since > branch-2.0 is almost the same with branch-2.1 now(except some new feature > on replication). Yes, agree that we should help out on branch-2.2. AMv2 > changed a lot in branch-2, there may still have some work to do to make > branch-2.2 stable. But at same time, I think we can mark branch-2.1 as > stable. We have done tremendous work on this branch, and recently ITBLLs > shows it is already stable enough(based on our internal version, but most > of patches in branch-2.1 was backported) > Best Regards > Allan Yang > > > Stack 于2018年11月12日周一 上午6:57写道： > >> Agree w/ Duo that the 2.x releases have been gated on stability watersheds >> rather than features. >> >> What else do we need to add to HBCK2 Duo (apart from a release)? >> >> Related, I was going to work on a 2.0.3 release. It has been a while and a >> bunch of good stability work has made it into branch-2.0. Thereafter >> though, I was going to let branch-2.0 go unless demand -- Allan Yang? -- >> and switch instead to helping out on branch-2.2. >> >> S >> >> On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) >> wrote: >> >> > I think for the 2.x release the problem is that we are still busy on >> making >> > the code stable, or speak more clearly, to make the procedure v2 >> framework >> > stable... And another big problem is lacking of HBCK2 support. These >> things >> > are all big issues which prevent people to upgrade to 2.x. >> > >> > Once these things are done, I think a monthly release will not be a big >> > problem to the RMs. Just simply run an ITBLL(for now it is not easy to >> get >> > a successful run and then we need to find out why...), and then the >> > make_rc.sh can not everything for you... >> > >> > Sean Busbey 于2018年11月9日周五 上午9:45写道： >> > >> > > I think it just shifts the RM burden, no? Like instead of watching >> e.g. >> > > branch-2.2 I instead need to watch branch-2. >> > > >> > > On Thu, Nov 8, 2018, 17:28 Josh Elser > > > >> > > > I think what I'd be concerned about WRT time-based releases is the >> > > > burden on RM to keep the branch in a good state. Perhaps we need to >> not >> > > > push that onto an RM and do better about sharing that load (looking >> in >> > > > the mirror). >> > > > >> > > > However, I do like time-based releases as a means to avoid "hurt >> > > > feelings" (e.g. the personal ties of a developer to a feature. "The >> > > > release goes out on /yy/xx, this feature is not yet ready, can >> go >> > > > out one month later.." etc) >> > > > >> > > > On 11/7/18 2:31 PM, Sean Busbey wrote: >> > > > > Hi folks! >> > > > > >> > > > > Some time ago we talked about trying to get back on track for a >> more >> > > > > regular cadence of minor releases rather than maintenance releases >> > > > > (like how we did back pre-1.0). That never quite worked out for >> the >> > > > > HBase 1.y line, but is still something we could make happen for >> HBase >> > > > > 2. >> > > > > >> > > > > We're coming up on 4 months since the 2.1 release line started. >> ATM >> > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in >> any >> > > > > 2.1.z version[1]. >> > > > > >> > > > > The main argument against starting to do a 2.2.0 release is that >> > > > > nothing springs out of that list as a "feature" that would entice >> > > > > users to upgrade. Waiting for these kinds of selling points to >> drive >> > a >> > > > > release is commonly referred to as "feature based releases." I >> think >> > > > > it would be fair to characterize the HBase 2.0 release as feature >> > > > > based centered on AMv2. >> > > > > >> > > > > An alternative to feature based releases is date based releases >> where >> > > > > we decide that e.g. we'll have a minor release each month >> regardless >> > > > > of how much is included in it. This is sometimes also called >> "train >> > > > > releases" as an analogy to how trains leave a station on a set >> > > > > schedule without regard to which individual passengers are ready. >> > Just >> > > > > as you'd catch the next scheduled train if you miss-timed your >> > > > > arrival, fixes or features that aren't ready just go in the next >> > > > > regular release. >> > > > > >> > > > >
Re: [DISCUSS] Release cadence for HBase 2.y
Stack, are you suggest about retiring branch-2.0? I think it is OK, since branch-2.0 is almost the same with branch-2.1 now(except some new feature on replication). Yes, agree that we should help out on branch-2.2. AMv2 changed a lot in branch-2, there may still have some work to do to make branch-2.2 stable. But at same time, I think we can mark branch-2.1 as stable. We have done tremendous work on this branch, and recently ITBLLs shows it is already stable enough(based on our internal version, but most of patches in branch-2.1 was backported) Best Regards Allan Yang Stack 于2018年11月12日周一 上午6:57写道： > Agree w/ Duo that the 2.x releases have been gated on stability watersheds > rather than features. > > What else do we need to add to HBCK2 Duo (apart from a release)? > > Related, I was going to work on a 2.0.3 release. It has been a while and a > bunch of good stability work has made it into branch-2.0. Thereafter > though, I was going to let branch-2.0 go unless demand -- Allan Yang? -- > and switch instead to helping out on branch-2.2. > > S > > On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) > wrote: > > > I think for the 2.x release the problem is that we are still busy on > making > > the code stable, or speak more clearly, to make the procedure v2 > framework > > stable... And another big problem is lacking of HBCK2 support. These > things > > are all big issues which prevent people to upgrade to 2.x. > > > > Once these things are done, I think a monthly release will not be a big > > problem to the RMs. Just simply run an ITBLL(for now it is not easy to > get > > a successful run and then we need to find out why...), and then the > > make_rc.sh can not everything for you... > > > > Sean Busbey 于2018年11月9日周五 上午9:45写道： > > > > > I think it just shifts the RM burden, no? Like instead of watching e.g. > > > branch-2.2 I instead need to watch branch-2. > > > > > > On Thu, Nov 8, 2018, 17:28 Josh Elser > > > > > > I think what I'd be concerned about WRT time-based releases is the > > > > burden on RM to keep the branch in a good state. Perhaps we need to > not > > > > push that onto an RM and do better about sharing that load (looking > in > > > > the mirror). > > > > > > > > However, I do like time-based releases as a means to avoid "hurt > > > > feelings" (e.g. the personal ties of a developer to a feature. "The > > > > release goes out on /yy/xx, this feature is not yet ready, can go > > > > out one month later.." etc) > > > > > > > > On 11/7/18 2:31 PM, Sean Busbey wrote: > > > > > Hi folks! > > > > > > > > > > Some time ago we talked about trying to get back on track for a > more > > > > > regular cadence of minor releases rather than maintenance releases > > > > > (like how we did back pre-1.0). That never quite worked out for the > > > > > HBase 1.y line, but is still something we could make happen for > HBase > > > > > 2. > > > > > > > > > > We're coming up on 4 months since the 2.1 release line started. ATM > > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in > any > > > > > 2.1.z version[1]. > > > > > > > > > > The main argument against starting to do a 2.2.0 release is that > > > > > nothing springs out of that list as a "feature" that would entice > > > > > users to upgrade. Waiting for these kinds of selling points to > drive > > a > > > > > release is commonly referred to as "feature based releases." I > think > > > > > it would be fair to characterize the HBase 2.0 release as feature > > > > > based centered on AMv2. > > > > > > > > > > An alternative to feature based releases is date based releases > where > > > > > we decide that e.g. we'll have a minor release each month > regardless > > > > > of how much is included in it. This is sometimes also called "train > > > > > releases" as an analogy to how trains leave a station on a set > > > > > schedule without regard to which individual passengers are ready. > > Just > > > > > as you'd catch the next scheduled train if you miss-timed your > > > > > arrival, fixes or features that aren't ready just go in the next > > > > > regular release. > > > > > > > > > > Personally, I really like the idea of doing date based releases for > > > > > minor releases with maintenance releases essentially only happening > > on > > > > > whatever our "stable" designator points at. It would mean those who > > > > > don't want the risk and benefits of our current release-ready work > > > > > could stay on a defined path while we could move away from > > maintaining > > > > > a ton of branches, some of which don't even see releases (currently > > ~3 > > > > > that are > 3 months since a release). If some folks had a specific > > > > > need for a different minor release line and were willing to do the > > > > > backport and RM work for that line, they'd of course be free to do > > so. > > > > > > > > > > I know there are some current unknowns around 2.2 specifically. I > > > > > think stack mentioned to me that there's an upgrade
[jira] [Created] (HBASE-21468) separate workers for meta table is not working
Allan Yang created HBASE-21468: -- Summary: separate workers for meta table is not working Key: HBASE-21468 URL: https://issues.apache.org/jira/browse/HBASE-21468 Project: HBase Issue Type: Bug Affects Versions: 2.0.2, 2.1.1 Reporter: Allan Yang Assignee: Allan Yang This is an addendum for HBASE-21423, since HBASE-21423 is already closed, the QA won't be triggered. It is my mistake that the separate workers for meta table is not working, since when polling from queue, the onlyUrgent flag is not passed in. And for some UT that only require one worker thread, urgent workers should set to 0 to ensure there is one worker at time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21423) Procedures for meta table/region should be able to execute in separate workers
[ https://issues.apache.org/jira/browse/HBASE-21423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang resolved HBASE-21423. Resolution: Fixed Opened HBASE-21468 for the addendum, close this one > Procedures for meta table/region should be able to execute in separate > workers > --- > > Key: HBASE-21423 > URL: https://issues.apache.org/jira/browse/HBASE-21423 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.1.1, 2.0.2 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 2.0.3, 2.1.2 > > Attachments: HBASE-21423.branch-2.0.001.patch, > HBASE-21423.branch-2.0.002.patch, HBASE-21423.branch-2.0.003.patch, > HBASE-21423.branch-2.0.addendum.patch > > > We have higher priority for meta table procedures, but only in queue level. > There is a case that the meta table is closed and a AssignProcedure(or RTSP > in branch-2+) is waiting there to be executed, but at the same time, all the > Work threads are executing procedures need to write to meta table, then all > the worker will be stuck and retry for writing meta, no worker will take the > AP for meta. > Though we have a mechanism that will detect stuck and adding more > ''KeepAlive'' workers to the pool to resolve the stuck. It is already stuck a > long time. > This is a real case I encountered in ITBLL. > So, I add one 'Urgent work' to the ProceudureExecutor, which only take meta > procedures(other workers can take meta procedures too), which can resolve > this kind of stuck. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Release cadence for HBase 2.y
Yes. Was suggesting retiring branch-2.0 and suggesting that we throw the troops against the branch-2.2 flank. Agree though that if there are folks who want more releases, lets do them (please speak up if this is so). 2.0.3 will be good since it close to 2.1.1. Unless demand, 2.0.4 will likely drag. In my limited testing (10B ITBLL), branch-2.1 (2.1.1) was making a good showing; better than what we've shipped previous in the past (in my estimation). Thanks Allan. (FYI branch-1.0 as short-lived if any consolation). S On Sun, Nov 11, 2018 at 6:12 PM Allan Yang wrote: > Stack, are you suggest about retiring branch-2.0? I think it is OK, since > branch-2.0 is almost the same with branch-2.1 now(except some new feature > on replication). Yes, agree that we should help out on branch-2.2. AMv2 > changed a lot in branch-2, there may still have some work to do to make > branch-2.2 stable. But at same time, I think we can mark branch-2.1 as > stable. We have done tremendous work on this branch, and recently ITBLLs > shows it is already stable enough(based on our internal version, but most > of patches in branch-2.1 was backported) > Best Regards > Allan Yang > > > Stack 于2018年11月12日周一 上午6:57写道： > > > Agree w/ Duo that the 2.x releases have been gated on stability > watersheds > > rather than features. > > > > What else do we need to add to HBCK2 Duo (apart from a release)? > > > > Related, I was going to work on a 2.0.3 release. It has been a while and > a > > bunch of good stability work has made it into branch-2.0. Thereafter > > though, I was going to let branch-2.0 go unless demand -- Allan Yang? -- > > and switch instead to helping out on branch-2.2. > > > > S > > > > On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) > > wrote: > > > > > I think for the 2.x release the problem is that we are still busy on > > making > > > the code stable, or speak more clearly, to make the procedure v2 > > framework > > > stable... And another big problem is lacking of HBCK2 support. These > > things > > > are all big issues which prevent people to upgrade to 2.x. > > > > > > Once these things are done, I think a monthly release will not be a big > > > problem to the RMs. Just simply run an ITBLL(for now it is not easy to > > get > > > a successful run and then we need to find out why...), and then the > > > make_rc.sh can not everything for you... > > > > > > Sean Busbey 于2018年11月9日周五 上午9:45写道： > > > > > > > I think it just shifts the RM burden, no? Like instead of watching > e.g. > > > > branch-2.2 I instead need to watch branch-2. > > > > > > > > On Thu, Nov 8, 2018, 17:28 Josh Elser > > > > > > > > I think what I'd be concerned about WRT time-based releases is the > > > > > burden on RM to keep the branch in a good state. Perhaps we need to > > not > > > > > push that onto an RM and do better about sharing that load (looking > > in > > > > > the mirror). > > > > > > > > > > However, I do like time-based releases as a means to avoid "hurt > > > > > feelings" (e.g. the personal ties of a developer to a feature. "The > > > > > release goes out on /yy/xx, this feature is not yet ready, can > go > > > > > out one month later.." etc) > > > > > > > > > > On 11/7/18 2:31 PM, Sean Busbey wrote: > > > > > > Hi folks! > > > > > > > > > > > > Some time ago we talked about trying to get back on track for a > > more > > > > > > regular cadence of minor releases rather than maintenance > releases > > > > > > (like how we did back pre-1.0). That never quite worked out for > the > > > > > > HBase 1.y line, but is still something we could make happen for > > HBase > > > > > > 2. > > > > > > > > > > > > We're coming up on 4 months since the 2.1 release line started. > ATM > > > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in > > any > > > > > > 2.1.z version[1]. > > > > > > > > > > > > The main argument against starting to do a 2.2.0 release is that > > > > > > nothing springs out of that list as a "feature" that would entice > > > > > > users to upgrade. Waiting for these kinds of selling points to > > drive > > > a > > > > > > release is commonly referred to as "feature based releases." I > > think > > > > > > it would be fair to characterize the HBase 2.0 release as feature > > > > > > based centered on AMv2. > > > > > > > > > > > > An alternative to feature based releases is date based releases > > where > > > > > > we decide that e.g. we'll have a minor release each month > > regardless > > > > > > of how much is included in it. This is sometimes also called > "train > > > > > > releases" as an analogy to how trains leave a station on a set > > > > > > schedule without regard to which individual passengers are ready. > > > Just > > > > > > as you'd catch the next scheduled train if you miss-timed your > > > > > > arrival, fixes or features that aren't ready just go in the next > > > > > > regular release. > > > > > > > > > > > > Personally, I really like the idea of doing date based releases > for >
[jira] [Created] (HBASE-21469) Re-visit post* hooks in DDL operations
Allan Yang created HBASE-21469: -- Summary: Re-visit post* hooks in DDL operations Key: HBASE-21469 URL: https://issues.apache.org/jira/browse/HBASE-21469 Project: HBase Issue Type: Bug Affects Versions: 2.0.2, 2.1.1 Reporter: Allan Yang Assignee: Allan Yang I have some discuss in HBASE-19953 from [here|https://issues.apache.org/jira/browse/HBASE-19953?focusedCommentId=16673126=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16673126] In HBASE-19953,[~elserj] want to make sure that the post* hooks are called only when the procedures finish.But it accidentally turns modifytable and truncate table request into a sync call, which make clients RPC timeout easily on big tables. We should re-visit those postxxx hooks in DDL operations, because they are now not consistent now: For DDLs other than modifytable and truncate table, although the call will wait on the latch, the latch is actually released just after prepare state, so we still call postxxx hooks before the operation finish. For DDLs of modifytable and truncate, the latch is only released after the whole procedure finish. So the effort works(but will cause RPC timeout) I think these latches are designed for compatibility with 1.x clients. Take ModifyTable for example, in 1.x, we use admin.getAlterStauts() to check the alter status, but in 2.x, this method is deprecated and returning inaccurate result, we have to make 1.x client in a sync wait. And for the semantics of postxxx hooks in 1.x, we will call them after the corresponding DDL request return, but actually, the DDL request may not finished also since we don't want for region assignment. So, here, we need to discuss the semantics of postxxx hooks in DDL operations, we need to make it consistent in every DDL operations, do we really need to make sure this hooks being called only after the operation finish? What's more, we have postCompletedxxx hooks for that need. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Release cadence for HBase 2.y
This makes me wonder if we have, or have a way to get, analytics about the version people are running? It's not great to guess about things like this. We're making a big assumption that our users actually pay attention to user@ or more often dev@ in order to complain about a branch being retired too quickly in time for us to listen. On Sun, Nov 11, 2018, 8:04 PM Stack Yes. Was suggesting retiring branch-2.0 and suggesting that we throw the > troops against the branch-2.2 flank. Agree though that if there are folks > who want more releases, lets do them (please speak up if this is so). 2.0.3 > will be good since it close to 2.1.1. Unless demand, 2.0.4 will likely > drag. > > In my limited testing (10B ITBLL), branch-2.1 (2.1.1) was making a good > showing; better than what we've shipped previous in the past (in my > estimation). > > Thanks Allan. > > (FYI branch-1.0 as short-lived if any consolation). > > S > > > > > > > > On Sun, Nov 11, 2018 at 6:12 PM Allan Yang wrote: > > > Stack, are you suggest about retiring branch-2.0? I think it is OK, since > > branch-2.0 is almost the same with branch-2.1 now(except some new feature > > on replication). Yes, agree that we should help out on branch-2.2. AMv2 > > changed a lot in branch-2, there may still have some work to do to make > > branch-2.2 stable. But at same time, I think we can mark branch-2.1 as > > stable. We have done tremendous work on this branch, and recently ITBLLs > > shows it is already stable enough(based on our internal version, but most > > of patches in branch-2.1 was backported) > > Best Regards > > Allan Yang > > > > > > Stack 于2018年11月12日周一 上午6:57写道： > > > > > Agree w/ Duo that the 2.x releases have been gated on stability > > watersheds > > > rather than features. > > > > > > What else do we need to add to HBCK2 Duo (apart from a release)? > > > > > > Related, I was going to work on a 2.0.3 release. It has been a while > and > > a > > > bunch of good stability work has made it into branch-2.0. Thereafter > > > though, I was going to let branch-2.0 go unless demand -- Allan Yang? > -- > > > and switch instead to helping out on branch-2.2. > > > > > > S > > > > > > On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) > > > wrote: > > > > > > > I think for the 2.x release the problem is that we are still busy on > > > making > > > > the code stable, or speak more clearly, to make the procedure v2 > > > framework > > > > stable... And another big problem is lacking of HBCK2 support. These > > > things > > > > are all big issues which prevent people to upgrade to 2.x. > > > > > > > > Once these things are done, I think a monthly release will not be a > big > > > > problem to the RMs. Just simply run an ITBLL(for now it is not easy > to > > > get > > > > a successful run and then we need to find out why...), and then the > > > > make_rc.sh can not everything for you... > > > > > > > > Sean Busbey 于2018年11月9日周五 上午9:45写道： > > > > > > > > > I think it just shifts the RM burden, no? Like instead of watching > > e.g. > > > > > branch-2.2 I instead need to watch branch-2. > > > > > > > > > > On Thu, Nov 8, 2018, 17:28 Josh Elser > > > > > > > > > > I think what I'd be concerned about WRT time-based releases is > the > > > > > > burden on RM to keep the branch in a good state. Perhaps we need > to > > > not > > > > > > push that onto an RM and do better about sharing that load > (looking > > > in > > > > > > the mirror). > > > > > > > > > > > > However, I do like time-based releases as a means to avoid "hurt > > > > > > feelings" (e.g. the personal ties of a developer to a feature. > "The > > > > > > release goes out on /yy/xx, this feature is not yet ready, > can > > go > > > > > > out one month later.." etc) > > > > > > > > > > > > On 11/7/18 2:31 PM, Sean Busbey wrote: > > > > > > > Hi folks! > > > > > > > > > > > > > > Some time ago we talked about trying to get back on track for a > > > more > > > > > > > regular cadence of minor releases rather than maintenance > > releases > > > > > > > (like how we did back pre-1.0). That never quite worked out for > > the > > > > > > > HBase 1.y line, but is still something we could make happen for > > > HBase > > > > > > > 2. > > > > > > > > > > > > > > We're coming up on 4 months since the 2.1 release line started. > > ATM > > > > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not > in > > > any > > > > > > > 2.1.z version[1]. > > > > > > > > > > > > > > The main argument against starting to do a 2.2.0 release is > that > > > > > > > nothing springs out of that list as a "feature" that would > entice > > > > > > > users to upgrade. Waiting for these kinds of selling points to > > > drive > > > > a > > > > > > > release is commonly referred to as "feature based releases." I > > > think > > > > > > > it would be fair to characterize the HBase 2.0 release as > feature > > > > > > > based centered on AMv2. > > > > > > > > > > > > > > An alternative to feature based releases is date based
[jira] [Created] (HBASE-21467) Fix flaky test TestCoprocessorClassLoader.testCleanupOldJars
OrDTesters created HBASE-21467:
--
Summary: Fix flaky test
TestCoprocessorClassLoader.testCleanupOldJars
Key: HBASE-21467
URL: https://issues.apache.org/jira/browse/HBASE-21467
Project: HBase
Issue Type: Bug
Environment: Ubuntu 18.04 LTS
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T13:33:14-05:00)
Maven home: /home/OrdTesters/apache-maven-3.5.4
Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
/usr/lib/jvm/jdk1.8.0_172/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-36-generic", arch: "amd64", family: "unix"
Reporter: OrDTesters
TestCoprocessorClassLoader.testCleanupOldJars fails when run by itself.
This can be fixed by calling CoprocessorClassLoader.getClassLoader, which
initializes the jar file needed by testCleanupOldJars.
Pull request: to be added
Steps to reproduce:
{code:java}
git clone https://github.com/apache/hbase
cd hbase/hbase-common
mvn install -DskipTests -am
mvn test -Dtest="TestCoprocessorClassLoader#testCleanupOldJars"{code}
Stack trace of the failure:
{code:java}
java.io.FileNotFoundException:
/home/OrdTesters/Java/hbase/hbase-common/target/test-data/64b7e1ae-1c34-48f7-d731-9af59256dc0a/hbase-local-dir/jars/tmp/TestCleanupOldJars.test.jar
(Aucun fichier ou dossier de ce type) at java.io.FileOutputStream.open0(Native
Method) at java.io.FileOutputStream.open(FileOutputStream.java:270) at
java.io.FileOutputStream.(FileOutputStream.java:213) at
java.io.FileOutputStream.(FileOutputStream.java:162) at
org.apache.hadoop.hbase.util.TestCoprocessorClassLoader.testCleanupOldJars(TestCoprocessorClassLoader.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
