Re: [DISCUSS] How to deal with the disabling of public sign ups for jira.a.o(enable github issues?)
Did other projects have the same solution for this, sync github issues to jira issues? Github issues will be useful to get more feedback. 张铎(Duo Zhang) 于2022年12月6日周二 00:13写道： > The PR for HBASE-27513 is available > > https://github.com/apache/hbase/pull/4913 > > Let's at least tell our users to send email to private@hbase for > acquiring a jira account. > > Thanks. > > 张铎(Duo Zhang) 于2022年12月2日周五 12:46写道： > > > > Currently all the comment on github PR will be sent to issues@hbase, > > like this one > > > > https://lists.apache.org/thread/jbfm269b4m24xl2r82l8b0t3pmqr44hr > > > > But I think this can only be used as an archive, to make sure that all > > discussions are recorded on asf infrastructure. > > > > For github issues, I'm afraid we can only do the same thing. As the > > format of github comment is different, it will be hard to read if we > > just sync the message to jira... > > > > Thanks. > > > > Bryan Beaudreault 于2022年12月1日周四 > 21:30写道： > > > > > > Should we have them sent to private@? Just thinking in terms of > reducing > > > spam to users who put their email and full name on a public list. > > > > > > One thought I had about bug tracking is whether we could use some sort > of > > > github -> jira sync. I've seen them used before, where it automatically > > > syncs issues and comments between the two systems. It's definitely not > > > ideal, but maybe an option? I'm guessing it would require INFRA help. > > > > > > On Thu, Dec 1, 2022 at 5:47 AM 张铎(Duo Zhang) > wrote: > > > > > > > I've filed HBASE-27513 for changing the readme on github. > > > > > > > > At least let's reuse the existing mailing list for acquiring jira > account. > > > > > > > > Thanks. > > > > > > > > 张铎(Duo Zhang) 于2022年11月29日周二 22:34写道： > > > > > > > > > > > > > > Bump and also send this to user@hbase. > > > > > > > > > > We need to find a way to deal with the current situation where > > > > > contributors can not create a Jira account on their own... > > > > > > > > > > At least, we need to change the readme on github page, web site and > > > > > also the ref guide to tell users how to acquire a jira account... > > > > > > > > > > Thanks. > > > > > > > > > > 张铎(Duo Zhang) 于2022年11月27日周日 22:06写道： > > > > > > > > > > > > For me, I think most developers already have a github account, so > > > > > > enabling it could help us get more feedback. For lots of younger > > > > > > Chinese developers, they rarely use email in their daily life... > > > > > > No doubt later we need to modify our readme on github. If we > just let > > > > > > users go to github issues on the readme, they will soon open an > issue > > > > > > there. But if we ask users to first send an email to a mailing > list, > > > > > > for acquiring a jira account, and then wait for a PMC member to > submit > > > > > > the request, and receive the email response, set up their > account, and > > > > > > then they can finally open an issue on jira. I'm afraid lots of > users > > > > > > will just give up, it is not very friendly... > > > > > > > > > > > > And I do not mean separate issue systems for users and devs. > Users can > > > > > > still open jira issues or ask in the mailing list if they want, > github > > > > > > issues is just another channel. If a user asks something in the > > > > > > mailing list and we think it is a bug, we will ask the user to > file an > > > > > > issue or we will file an issue for it. It is just the same with > github > > > > > > issues. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Nick Dimiduk 于2022年11月24日周四 15:44写道： > > > > > > > > > > > > > > This new situation around JIRA seems very similar to the > existing > > > > situation > > > > > > > around Slack. A new community member currently must acquire a > Slack > > > > invite > > > > > > > somehow, usually by emailing one of the lists. Mailing lists > > > > themselves > > > > > > > involve a signup process, though it may be possible to email > > > > user/-zh/dev > > > > > > > without first subscribing to the list. > > > > > > > > > > > > > > I have a -0 opinion on using GitHub Issues to manage JIRA > > > > subscription > > > > > > > access. It seems like a comical cascade of complexity. I’d > prefer to > > > > keep > > > > > > > GitHub Issues available to us as a future alternative to JIRA > for > > > > project > > > > > > > issue tracking. I agree with you that migrating away from JIRA > will > > > > be > > > > > > > painful. > > > > > > > > > > > > > > I’m not a big fan of having separate issue systems for users > vs. > > > > devs. It > > > > > > > emphasizes the idea that users and devs are different groups of > > > > people with > > > > > > > unequal voice in the project direction. I suppose it could be > done > > > > well, > > > > > > > but I think it is more likely to be done poorly. > > > > > > > > > > > > > > I follow the Infra list, but only casually. It seems there’s a > plan > > > > to > > > > > > > eventually adopt some Atlassian Cloud service, which
Re: [ANNOUNCE] New HBase Committer Liangjun He
Congratulations! OpenInx 于2022年12月6日周二 19:03写道： > Congrats and welcome ! > > On Tue, Dec 6, 2022 at 2:21 AM Andrew Purtell wrote: > > > Congratulations, and welcome! > > > > On Sat, Dec 3, 2022 at 5:51 AM Yu Li wrote: > > > > > Hi All, > > > > > > On behalf of the Apache HBase PMC, I am pleased to announce that > Liangjun > > > He (heliangjun) has accepted the PMC's invitation to become a committer > > on > > > the project. We appreciate all of Liangjun's generous contributions > thus > > > far and look forward to his continued involvement. > > > > > > Congratulations and welcome, Liangjun! > > > > > > 我很高兴代表 Apache HBase PMC 宣布 Liangjun He (何良均) 已接受我们的邀请，成为 Apache HBase > 项目的 > > > Committer。感谢何良均一直以来为 HBase 项目做出的贡献，并期待他在未来继续承担更多的责任。 > > > > > > 欢迎良均！ > > > > > > Best Regards, > > > Yu > > > -- > > > Best Regards, > > > Yu > > > > > > > > > -- > > Best regards, > > Andrew > > > > Unrest, ignorance distilled, nihilistic imbeciles - > > It's what we’ve earned > > Welcome, apocalypse, what’s taken you so long? > > Bring us the fitting end that we’ve been counting on > >- A23, Welcome, Apocalypse > > >
[jira] [Created] (HBASE-27520) The potential delay of HDFS RPC in HRegion may cause data inconsistency
Haoze Wu created HBASE-27520:
Summary: The potential delay of HDFS RPC in HRegion may cause data
inconsistency
Key: HBASE-27520
URL: https://issues.apache.org/jira/browse/HBASE-27520
Project: HBase
Issue Type: Bug
Affects Versions: 2.4.2
Reporter: Haoze Wu
This is a follow-up for HBASE-26256 about the data inconsistency issue.
The data inconsistency issue is that when the HBase shell is running the
`create` command, the metadata is not finalized or committed until the shell
command returns, but other clients can see the table “created” when they use
the “list” command. We recently did more analysis and found the root cause.
Here is the workflow. When a table is created, the CreateTableProcedure is
created at HMaster#createTable at line 2011:
{code:java}
return MasterProcedureUtil
.submitProcedure(new MasterProcedureUtil.NonceProcedureRunnable(this,
nonceGroup, nonce) {
@Override
protected void run() throws IOException {
getMaster().getMasterCoprocessorHost().preCreateTable(desc, newRegions);
LOG.info(getClientIdAuditPrefix() + " create " + desc);
// TODO: We can handle/merge duplicate requests, and differentiate the
case of
// TableExistsException by saying if the schema is the same or not.
//
// We need to wait for the procedure to potentially fail due to "prepare"
sanity
// checks. This will block only the beginning of the procedure. See
HBASE-19953.
ProcedurePrepareLatch latch = ProcedurePrepareLatch.createBlockingLatch();
submitProcedure(
new CreateTableProcedure(procedureExecutor.getEnvironment(), desc,
newRegions, latch)); // line 2011
latch.await();
getMaster().getMasterCoprocessorHost().postCreateTable(desc, newRegions);
}
@Override
protected String getDescription() {
return "CreateTableProcedure";
}
});{code}
The its call stack is:
{code:java}
org.apache.hadoop.hbase.master.HMaster,createTable,1995
org.apache.hadoop.hbase.master.MasterRpcServices,createTable,705
org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2,callBlockingMethod,108919
org.apache.hadoop.hbase.ipc.RpcServer,call,395
org.apache.hadoop.hbase.ipc.CallRunner,run,133
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler,run,338
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler,run,318 {code}
`CreateTableProcedure` is submitted at line 2011. It will eventually call
CreateTableProcedure#executeFromState in HMaster.
CreateTableProcedure#executeFromState runs a state machine. It exercises 3
states, one after another (via the loop in ProcedureExecutor#executeProcedure):
# `CREATE_TABLE_ADD_TO_META` state. It will add table info to the hbase::meta.
# `CREATE_TABLE_ASSIGN_REGIONS` state. It will create a subprocedure, which
makes an AssignmentManager in master connect to regionservers to distribute the
region create command.
# `CREATE_TABLE_UPDATE_DESC_CACHE` state. It finalizes the region creation.
Code snippet (CreateTableProcedure#executeFromState, line 105 ~ 120):
{code:java}
case CREATE_TABLE_ADD_TO_META:
newRegions = addTableToMeta(env, tableDescriptor, newRegions);
setNextState(CreateTableState.CREATE_TABLE_ASSIGN_REGIONS);
break;
case CREATE_TABLE_ASSIGN_REGIONS:
setEnablingState(env, getTableName());
addChildProcedure(env.getAssignmentManager()
.createRoundRobinAssignProcedures(newRegions));
setNextState(CreateTableState.CREATE_TABLE_UPDATE_DESC_CACHE);
break;
case CREATE_TABLE_UPDATE_DESC_CACHE:
// XXX: this stage should be named as set table enabled, as now we will cache
the
// descriptor after writing fs layout.
setEnabledState(env, getTableName());
setNextState(CreateTableState.CREATE_TABLE_POST_OPERATION);
break;{code}
When the issue described in HBASE-26256 appears, it is in the
`CREATE_TABLE_ASSIGN_REGIONS` state. The subprocedure calling regionserver is
stuck for a while, so the state machine is not able to proceed to the
`CREATE_TABLE_UPDATE_DESC_CACHE` state temporarily. However, at this moment,
when other clients run the `list` command, they are essentially only checking
the meta variable field in this HMaster and print this table, although the
state machine here is still stuck at the `CREATE_TABLE_ASSIGN_REGIONS` and this
table is actually not yet fully created. Therefore, the inconsistency happens.
To fix this issue, we need to slightly change the state machine or add some
auxiliary flags for the tables to mark whether the table is still under the
procedure of being created. We think the latter is better because changing the
state machine may involve lots of modification.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [ANNOUNCE] New HBase Committer Liangjun He
Congrats and welcome ! On Tue, Dec 6, 2022 at 2:21 AM Andrew Purtell wrote: > Congratulations, and welcome! > > On Sat, Dec 3, 2022 at 5:51 AM Yu Li wrote: > > > Hi All, > > > > On behalf of the Apache HBase PMC, I am pleased to announce that Liangjun > > He (heliangjun) has accepted the PMC's invitation to become a committer > on > > the project. We appreciate all of Liangjun's generous contributions thus > > far and look forward to his continued involvement. > > > > Congratulations and welcome, Liangjun! > > > > 我很高兴代表 Apache HBase PMC 宣布 Liangjun He (何良均) 已接受我们的邀请，成为 Apache HBase 项目的 > > Committer。感谢何良均一直以来为 HBase 项目做出的贡献，并期待他在未来继续承担更多的责任。 > > > > 欢迎良均！ > > > > Best Regards, > > Yu > > -- > > Best Regards, > > Yu > > > > > -- > Best regards, > Andrew > > Unrest, ignorance distilled, nihilistic imbeciles - > It's what we’ve earned > Welcome, apocalypse, what’s taken you so long? > Bring us the fitting end that we’ve been counting on >- A23, Welcome, Apocalypse >
