[jira] [Created] (HBASE-27766) Support steal job queue mode for read RPC queues of RWQueueRpcExecutor
Xiaolin Ha created HBASE-27766: -- Summary: Support steal job queue mode for read RPC queues of RWQueueRpcExecutor Key: HBASE-27766 URL: https://issues.apache.org/jira/browse/HBASE-27766 Project: HBase Issue Type: Improvement Components: rpc Affects Versions: 2.5.3, 3.0.0-alpha-3 Reporter: Xiaolin Ha Assignee: Xiaolin Ha Currently, the RPC queues are distinguished by request type, under most circumstances of RWQueueRpcExecutor, there are write queues and read queues, while reads queues are always divided by get requests and scan requests. The reason why we isolate the scan requests and get requests is that we do not want large scans block small gets. Since the handler resources for a regionserver is limited and we can't dynamicly change the handler ratio by the ratio of requests. We should both keep large scan the small gets be isolated, and let the idle handlers for the samller ratio scans to handle some gets when the gets handlers are busy. This steal queue idea can also used in other circumstances, e.g. idle read handler steal jobs from write queus. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Branching for 2.6 code line (branch-2.6)
I think we could follow the old pattern when we cut a new release branch. That is, after the new release branch is cut and the new minor release is out, we will do a final release of the oldest release line and then mark it as EOL. So here, I think once we cut branch-2.6 and release 2.6.0, we can do a final release for 2.4.x and mark 2.4.x as EOL. Thanks. Bryan Beaudreault 于2023年3月27日周一 09:57写道： > Primary development on hbase-backup and TLS is complete. There are a couple > minor things I may want to add to TLS in the future, such as pluggable cert > verification. But those are not needed for initial release IMO. > > We are almost ready integrating hbase-backup in production. We’ve fixed a > few minor things (all committed) but otherwise it’s worked well so far in > tests. > > We are a bit delayed in integrating TLS. I’m hopeful it will happen in the > next 2-3 months. It’s a big project for us, so not quick, but definitely on > the roadmap. > > It seems like cloudera may be closer to integrating TLS in production. > Balazs recently filed and fixed HBASE-27673 related to mTLS. Maybe he can > chime in on his status, or let me know if I am totally off base :) > > On Sun, Mar 26, 2023 at 9:25 PM Andrew Purtell > wrote: > > > Before we open a new code line should we discuss EOL of 2.4? After the > > first 2.6 release? It’s not required of course but cuts down the amount > of > > labor to have two 2.x code lines (presumably, one as stable and one as > > next) rather than three. Perhaps even before that, should we move the > > stable pointer to the latest 2.5 release? > > > > > > > > On Mar 26, 2023, at 5:59 PM, 张铎 wrote: > > > > > > Bump. > > > > > > I believe the mTLS and backup related code have all been finished on > > > branch-2? > > > > > > Are there any other things which block us making the branch-2.6 branch? > > > > > > Thanks. > > > > > > Mallikarjun 于2022年10月17日周一 02:09写道： > > > > > >> On hbase-backup, we are using in production for more then 1 year. I > can > > >> vouch for it to be stable enough to be in a release version so that > more > > >> people can use it and polished it further. > > >> > > >>> On Sun, Oct 16, 2022, 11:25 PM Andrew Purtell < > > andrew.purt...@gmail.com> > > >>> wrote: > > >>> > > >>> My understanding is some folks evaluating and polishing TLS for their > > >>> production are also considering hbase-backup in the same way, which > is > > >> why > > >>> I linked them together. If that is incorrect then they both are still > > >> worth > > >>> considering in my opinion but would have a more tenuous link. > > >>> > > >>> Where we are with hbase-backup is it should probably be ported to > where > > >>> more people would be inclined to evaluate it, in order for it to make > > >> more > > >>> progress. A new minor releasing line would fit. On the other hand if > it > > >> is > > >>> too unpolished then the experience would be poor. > > >>> > > >>> > > On Oct 16, 2022, at 5:35 AM, 张铎 wrote: > > > > I believe the second one is still ongoing? > > > > Andrew Purtell 于2022年10月14日周五 05:37写道： > > > > > > We will begin releasing activity for the 2.6 code line and as a > > > prerequisite to that we shall need to make a new branch branch-2.6 > > >> from > > > branch-2. > > > > > > Before we do that let's make sure all commits for the key features > of > > >>> 2.6 > > > are settled in branch-2 before the branching point. Those key > > features > > >>> are: > > > - mTLS RPC > > > - hbase-backup backport > > > > > > -- > > > Best regards, > > > Andrew > > >>> > > >> > > >
[jira] [Created] (HBASE-27765) Add biggest cell related info web ui
Zheng Wang created HBASE-27765: -- Summary: Add biggest cell related info web ui Key: HBASE-27765 URL: https://issues.apache.org/jira/browse/HBASE-27765 Project: HBase Issue Type: Improvement Components: HFile, UI Reporter: Zheng Wang Assignee: Zheng Wang There are some disadvantages to large cell, such as can't be cached or cause memory fragmentation, but currently user can't easily to find them out. My proposal is save len and key of the biggest cell into fileinfo of hfile, and shown on web ui, including two places. 1: Add "Len Of Biggest Cell" into main page of regionServer, in here we can find out which regions has large cell by sorting. 2: Add "Len Of Biggest Cell" and "Key Of Biggest Cell" into region page, in here we can find out the exactly key and the hfile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
A Message from the Board to PMC members
Dear Apache Project Management Committee (PMC) members, The Board wants to take just a moment of your time to communicate a few things that seem to have been forgotten by a number of PMC members, across the Foundation, over the past few years. Please note that this is being sent to all projects - yours has not been singled out. The Project Management Committee (PMC) as a whole[1] is tasked with the oversight, health, and sustainability of the project. The PMC members are responsible collectively, and individually, for ensuring that the project operates in a way that is in line with ASF philosophy, and in a way that serves the developers and users of the project. The PMC Chair is not the project leader, in any sense. It is the person who files board reports and makes sure they are delivered on time. It is the secretary for the project, and the project’s ambassador to the Board of Directors. The VP title is given as an artifact of US corporate law, and not because the PMC Chair has any special powers. If you are treating your PMC Chair as the project lead, or granting them any other special powers or privileges, you need to be aware that that’s not the intent of the Chair role. The Chair is a PMC member peer with a few extra duties. Every PMC member has an equal voice in deliberations. Each has one vote. Each has veto power. Every vote weighs the same. It is not only your right, but it is your obligation, to use that vote for the good of the project and its users, not to appease the Chair, your employer, or any other voice in the project. Every PMC member can, and should, nominate new committers, and new PMC members. This is not the sole domain of the PMC Chair. This might be your most important responsibility to the project, as succession planning is the path to sustainability. Every PMC member can, and should, respond when the Board sends email to your private list. You should not wait for the PMC Chair to respond. The Board views the entire PMC as responsible for the project, not just one member. Every PMC member should be subscribed to the private@ mailing list. If you are not, then you are neglecting your duty of oversight. If you no longer wish to be responsible for oversight of the project, you should resign your PMC seat, not merely drop off of the private@ list and ignore it. You can determine which PMC members are not subscribed to your private list by looking at your PMC roster at https://whimsy.apache.org/roster/committee/ Names with an asterisk (*) next to them are not subscribed to the list. We encourage you to take a moment to contact them with this information. Thank you for your attention to these matters, and thank you for keeping our projects healthy. Rich, for The Board of Directors [1] https://apache.org/foundation/how-it-works.html#pmc-members
[jira] [Resolved] (HBASE-27726) ruby shell not handled SyntaxError exceptions properly
[ https://issues.apache.org/jira/browse/HBASE-27726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla resolved HBASE-27726. - Resolution: Fixed > ruby shell not handled SyntaxError exceptions properly > -- > > Key: HBASE-27726 > URL: https://issues.apache.org/jira/browse/HBASE-27726 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.5.2 >Reporter: chiranjeevi >Assignee: Rishabh Murarka >Priority: Minor > Fix For: 2.6.0, 3.0.0-alpha-4, 2.4.17, 2.5.4 > > > hbase:002:0> create 't2', 'cf' > 2023-03-14 04:54:50,061 INFO [main] client.HBaseAdmin: Operation: CREATE, > Table Name: default:t2, procId: 2140 completed > Created table t2 > Took 1.1503 seconds > => Hbase::Table - t2 > hbase:003:0> alter 't2', NAME ⇒ 'cf', VERSIONS ⇒ 5 > SyntaxError: (hbase):3: syntax error, unexpected tIDENTIFIER > alter 't2', NAME ⇒ 'cf', VERSIONS ⇒ 5 > ^~~ > eval at org/jruby/RubyKernel.java:1091 > evaluate at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/workspace.rb:85 > evaluate at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/context.rb:385 > eval_input at uri:classloader:/irb/hirb.rb:115 > signal_status at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:647 > eval_input at uri:classloader:/irb/hirb.rb:112 > each_top_level_statement at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:246 > loop at org/jruby/RubyKernel.java:1507 > each_top_level_statement at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:232 > catch at org/jruby/RubyKernel.java:1237 > each_top_level_statement at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:231 > eval_input at uri:classloader:/irb/hirb.rb:111 > run at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:428 > catch at org/jruby/RubyKernel.java:1237 > run at > uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:427 > at classpath:/jar-bootstrap.rb:226 -- This message was sent by Atlassian Jira (v8.20.10#820010)
