av9ash/GitBugs huggingface dataset:
Bug: Rubocop configuration needs updated
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 05/Mar/20 19:27
Affects Version/s: 1.7.0

Looking at the general check output on [nightly/master|https://builds.apache.org/blue/organizations/jenkins/HBase%20Nightly/detail/master/1654/pipeline/96/], it looks like our {{.rubocop.yaml}} configuration file has drifted from the syntax expected by our current version of the tool. Lots of errors like the following:

{noformat}
[2020-03-05T15:36:27.538Z] Running rubocop against identified ruby scripts.
[2020-03-05T15:36:27.538Z] .rubocop.yml: Metrics/LineLength has the wrong namespace - should be Layout
[2020-03-05T15:36:27.538Z] Error: The `Layout/IndentHeredoc` cop has been renamed to `Layout/HeredocIndentation`.
[2020-03-05T15:36:27.538Z] (obsolete configuration found in .rubocop.yml, please update it)
[2020-03-05T15:36:27.538Z] .rubocop.yml: Metrics/LineLength has the wrong namespace - should be Layout
[2020-03-05T15:36:27.538Z] Error: The `Layout/IndentHeredoc` cop has been renamed to `Layout/HeredocIndentation`.
[2020-03-05T15:36:27.538Z] (obsolete configuration found in .rubocop.yml, please update it)
...
{noformat}
Bug: Consider using 127.0.0.1 instead of localhost and binding to 127.0.0.1 as well.
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 04/Feb/20 17:25

This is perhaps controversial, but there are a variety of problems with counting on dns hostname resolution, especially for locahost.

 
 # It can often be slow, slow under concurrency, or slow under specific conditions.
 # It can often not work at all - when on a VPN, with weird DNS hijacking hi-jinks, when you have a real hostname for you machines, a custom /etc/hosts file, OS's run their own local/funny DNS server services.
 # This makes coming to HBase for new devs a hit or miss experience and if you miss, dealing with an diagnosing the issues is a large endeavor and not straight forward or transparent.
 #  99% of the difference doesn't matter in most cases - except that 127.0.0.1 works and is fast pretty much universally.
Bug: remove_servers_rsgroup did not get the correct result
Status: Open | Priority: Minor | Resolution: 
Created: 27/Feb/20 11:21
Affects Version/s: 2.2.3

While trying to remove a server from a rs group, if the rs group is not valid/present in the rs group, it still shows *0 row(s)*, instead of an *exception "Server Invalid/Not found"*.
Bug: Consider setting -XX:MaxDirectMemorySize in the root Maven pom.xml file.
Status: Open | Priority: Minor | Resolution: 
Created: 04/Feb/20 17:02

-XX:MaxDirectMemorySize is an artificial governor on how much off heap memory can be allocated.

It would be nice to specify explicitly because:
 # The default can vary by platform / jvm impl - some devs may see random fails
 # It's just a limiter, it won't pre allocate or anything
 # A test env should normally ensure a healthy limit as would be done in production
Bug: Re-use underlying connection registry in RawAsyncHBaseAdmin
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 06/Jan/20 02:14
Affects Version/s: 3.0.0-alpha-1

Based on the discussion between [~stack] and I in the code review for HBASE-23305, the current usage of ConnectionRegistry is ad-hoc, sometimes multiple times per connection.

Before Duo's Comment: don't see any obvious reason to not make it a singleton (except for testing). This makes it more readable.

Edited to: Fix RawAsyncHBaseAdmin's creation of adhoc registry.
Bug: [RSGroup] Error logs appear when the table is created
Status: Open | Priority: Minor | Resolution: 
Created: 27/Mar/20 11:07
Affects Version/s: 2.1.7

Will create table assigned to the corresponding rsgroup, appear TableStateNotFoundException:
{code:java}
2020-03-27 15:49:21,959 INFO  [RpcServer.default.RWQ.Fifo.read.handler=139,queue=14,port=16000] rsgroup.RSGroupAdminServer: Moving table Test:t3 to RSGroup default
2020-03-27 15:49:21,971 ERROR [RpcServer.default.RWQ.Fifo.read.handler=139,queue=14,port=16000] master.TableStateManager: Unable to get table Test:t3 state
org.apache.hadoop.hbase.master.TableStateManager$TableStateNotFoundException: Test:t3
        at org.apache.hadoop.hbase.master.TableStateManager.getTableState(TableStateManager.java:215)
        at org.apache.hadoop.hbase.master.TableStateManager.isTableState(TableStateManager.java:147)
        at org.apache.hadoop.hbase.master.assignment.AssignmentManager.isTableDisabled(AssignmentManager.java:388)
        at org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTableRegionsToGroup(RSGroupAdminServer.java:252)
        at org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:366)
        at org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.assignTableToGroup(RSGroupAdminEndpoint.java:447)
        at org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.postCreateTable(RSGroupAdminEndpoint.java:470)
        at org.apache.hadoop.hbase.master.MasterCoprocessorHost$13.call(MasterCoprocessorHost.java:350)
        at org.apache.hadoop.hbase.master.MasterCoprocessorHost$13.call(MasterCoprocessorHost.java:347)
        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.master.MasterCoprocessorHost.postCreateTable(MasterCoprocessorHost.java:347)
        at org.apache.hadoop.hbase.master.HMaster$4.run(HMaster.java:2043)
        at org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:134)
        at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:2026)
        at org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:659)
        at org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
        at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:413)
        at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
        at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:338)
        at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:318)
2020-03-27 15:49:21,971 INFO  [RpcServer.default.RWQ.Fifo.read.handler=139,queue=14,port=16000] rsgroup.RSGroupAdminServer: Moving region(s) for table Test:t3 to RSGroup default
 
{code}
 

This doesn't seem to cause any problems, but I think it's best to avoid error logs like this
Bug: Solve the ambiguous reference for scala 2.12
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 31/Mar/20 05:04

When the {{hbase-spark}} module is compiled under the scala 2.12 environment, the following error appears in line 216 of the {{org.apache.hadoop.hbase.spark.datasources.HBaseTableScanRDD}} class:
{code:java}
[ERROR] [Error] /path/hbase-connectors/spark/hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/datasources/HBaseTableScanRDD.scala:216: ambiguous reference to overloaded definition, both method addTaskCompletionListener in class TaskContext of type [U](f: org.apache.spark.TaskContext => U)org.apache.spark.TaskContext and method addTaskCompletionListener in class TaskContext of type (listener: org.apache.spark.util.TaskCompletionListener)org.apache.spark.TaskContext match argument types (org.apache.spark.TaskContext => Unit){code}
Bug: Fix links to build reports generated by nightly job
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 31/Mar/20 16:00
Affects Version/s: 2.3.0

Links going back to JIRA look like

{noformat}
For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2574//JDK8_Nightly_Build_Report_(Hadoop2)/]
{noformat}

But the actual URL to this report is https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2574/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/
Bug: SpotBugs check automatically skip inapplicable modules
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Mar/20 15:55

Our personality runs spotbugs on a per-module basis, rather than from the root module. It has a hard-coded list of modules to skip over. The comment says it only runs on modules that have content under {{src/main/java}}. Replace the fixed list with a find expression.
Bug: TestHRegion.testCheckAndMutate_WithFilters is flaky
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 21/Mar/20 08:51

{code}
[ERROR] Tests run: 108, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 119.165 s <<< FAILURE! - in org.apache.hadoop.hbase.regionserver.TestHRegion
[ERROR] org.apache.hadoop.hbase.regionserver.TestHRegion.testCheckAndMutate_WithFilters  Time elapsed: 0.179 s  <<< FAILURE!
java.lang.AssertionError: expected:<d> but was:<null>
        at org.apache.hadoop.hbase.regionserver.TestHRegion.testCheckAndMutate_WithFilters(TestHRegion.java:2218)
{code}

This happens only in the master branch.
Bug: Fix pylint invocation in pre-commit
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 27/Jan/20 18:14

Seems Yetus and our version of pylint disagree on executable arguments. From a recent pre-commit check over a python file:

{noformat}
Usage:  pylint [options] module_or_package

  Check that a module satisfies a coding standard (and more !).

    pylint --help

  Display this help message and exit.

    pylint --help-msg <msg-id>[,<msg-id>]

  Display help messages about given message identifiers and exit.


pylint: error: no such option: --score
{noformat}
Bug: protoc warns: "no protobuf syntax specified"
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 11/Mar/20 23:29

This comes up in a couple places.

{noformat}
[INFO] --- protobuf-maven-plugin:0.6.1:compile (compile-protoc) @ hbase-protocol-shaded ---
[INFO] Compiling 37 proto file(s) to /Users/ndimiduk/repos/apache/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
[WARNING] PROTOC: [libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: RSGroupAdmin.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: RSGroup.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
{noformat}
Bug: Add an option to Actions to filter out meta RS
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Feb/20 14:04
Affects Version/s: 3.0.0-alpha-1

Add an option to Actions to be able to filter meta server out. 

Some ITs rely on meta RS and have timeout errors if this RS is killed. (e.g. IntegrationTestTimeBoundedRequestsWithRegionReplicas)

For the time being there is no option for removing meta server from server list to kill or configuring these actions properly.

The following chaos monkey actions are affected: GracefulRollingRestartRsAction, RollingBatchSuspendResumeRsAction
Bug: Add CI check that builds dockerfiles
Status: Open | Priority: Minor | Resolution: 
Created: 10/Mar/20 19:23

I stumbled into some bit-rot in a {{Dockerfile}} recently. The job that powers the flakey detector apparently only runs because the build machines have layers cached. We could detect these failures earlier by rebuilding docker environments with {{--no-cache}} on a regular interval. Nightly is probably overkill, but it's easy enough to tack on an additional parallel stage to the existing build.
Bug: list_rsgroups didn't get the correct result
Status: Resolved | Priority: Minor | Resolution: Invalid
Created: 23/Feb/20 01:54
Affects Version/s: 2.2.3

if my_group does not exist, list_rsgroups will get 0 row(s),
 but i think list_rsgroups should throw NOTEXISTEXCEPTION

!image-2020-02-23-09-53-49-594.png|width=449,height=143!
Bug: Shell formatter for for meta table should pretty-print values of info:merge columns
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 04/Mar/20 22:17
Affects Version/s: 2.3.0

Diagnosing mangled region assignments, scanning meta from the shell, we see regions with {{info:merge000X}} cells, but their values are printed as encoded protobuf. We should have a {{Formatter}} in place that can decode these values into something legible for a human.
Bug: Add test for MinVersions and KeepDeletedCells TTL
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 20/Jan/20 21:30

Recently I was researching how HBase handles the interactions between setting MinVersions and KeepDeletedCells = TTL, and I wrote a test to prove my assumptions about the behavior were correct. There doesn't seem to be an equivalent existing test in TestMinVersions, so I thought I'd contribute it.
Bug: Make sure HBaseClassTestRule doesn't suffer same issue as HBaseClassTestRuleChecker
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 16/Jan/20 20:31

[~bharathv] pointed out on HBASE-23695 ([https://github.com/apache/hbase/pull/1052]) that HBaseClassTestRule suffers the same potential bug that I fixed in HBASE-23695 for HBaseClassTestRuleChecker. Make sure the fix is in both places.
Bug: [JDK11] Yetus should vote -0 for known JDK11 issues
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 06/Mar/20 16:21

So as t avoid everyone being depressed by failing builds, we should have Yetus vote -0 instead of -1 for checks that are known to fail with JDK11. Off the top of my head, these should be {{javadocs}} and {{unit}}.
Bug: Invalid StoreFile WARN log message printed for recovered.hfiles directory
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 27/Jan/20 06:13
Affects Version/s: 2.3.0

After HBASE-23286, recovered.hfiles directories will be created under table CF dir. Region server validates the store file during store initializaiton. Currently it expect only store file inside the table CF directory, so for recovered.hfiles below WARN logs message will be printed.
{code:java}
2020-01-27 11:13:09,823 WARN [StoreOpener-1588230740-1] regionserver.HRegionFileSystem: Invalid StoreFile: hdfs://127.0.0.1:8020/hbase/data/hbase/meta/1588230740/info/recovered.hfiles
2020-01-27 11:14:31,036 WARN [StoreOpener-1588230740-1] regionserver.HRegionFileSystem: Invalid StoreFile: hdfs://127.0.0.1:8020/hbase/data/hbase/meta/1588230740/info/recovered.hfiles
2020-01-27 11:14:31,110 WARN [StoreOpener-1588230740-1] regionserver.HRegionFileSystem: Invalid StoreFile: hdfs://127.0.0.1:8020/hbase/data/hbase/meta/1588230740/table/recovered.hfiles
2020-01-27 11:14:36,031 WARN [StoreOpener-16beeb2fd517283980b11b912490cbba-1] regionserver.HRegionFileSystem: Invalid StoreFile: hdfs://127.0.0.1:8020/hbase/data/default/t4/16beeb2fd517283980b11b912490cbba/cf1/recovered.hfiles
2020-01-27 11:14:36,057 WARN [StoreOpener-e430213f4660304a26b9b389f78b5681-1] regionserver.HRegionFileSystem: Invalid StoreFile: hdfs://127.0.0.1:8020/hbase/data/hbase/acl/e430213f4660304a26b9b389f78b5681/l/recovered.hfiles
{code}

No need to validate recovered.hfiles directory.
Bug: Backport "HBASE-18418 Remove apache_hbase_topology from dev-support" to branch-2
Status: Resolved | Priority: Minor | Resolution: Duplicate
Created: 06/Mar/20 17:10
Affects Version/s: 2.3.0

HBASE-23945 flags this dockerfile as having issues, but it's been deleted from master. Drop it from branch-2 as well.
Bug: [Jenkins Nightly] shelldocs executable unavailable within docker context
Status: Open | Priority: Minor | Resolution: 
Created: 05/Mar/20 19:20
Affects Version/s: 3.0.0-alpha-1

I'm not sure if this is an HBase build bug or a Yetus bug. Looking more closely at the yetus output, I noticed this in the general check section on [nightlies/master|https://builds.apache.org/blue/organizations/jenkins/HBase%20Nightly/detail/master/1654/pipeline/96].

{noformat}
[2020-03-05T14:56:51.559Z] executable '/home/jenkins/jenkins-slave/workspace/HBase_Nightly_master/yetus-0.11.1/bin/shelldocs' for 'shelldocs' does not exist.
{noformat}

Of course the executable is available in the yetus distro unpacked into the workspace. However, we're running in the docker context, and apparently the yetus runtime does not make itself available to the running container.
Bug: [flakey] TestThriftHttpServer fails to bind to port
Status: Open | Priority: Minor | Resolution: 
Created: 26/Feb/20 18:08
Affects Version/s: 2.3.0

We see thrift tests fail occasionally in Jenkins due to failure to bind to port.

{noformat}
2020-02-26 10:24:07,725 INFO  [ThriftServer-httpServer] http.HttpServer (HttpServer.java:start(1063)) - HttpServer.start() threw a non Bind IOException
java.net.BindException: Port in use: 0.0.0.0:54902
	at org.apache.hadoop.hbase.http.HttpServer.openListeners(HttpServer.java:1126)
	at org.apache.hadoop.hbase.http.HttpServer.start(HttpServer.java:1060)
	at org.apache.hadoop.hbase.http.InfoServer.start(InfoServer.java:148)
	at org.apache.hadoop.hbase.thrift.ThriftServer.startInfoServer(ThriftServer.java:308)
	at org.apache.hadoop.hbase.thrift.ThriftServer.run(ThriftServer.java:849)
	at org.apache.hadoop.hbase.thrift.TestThriftHttpServer.lambda$startHttpServerThread$0(TestThriftHttpServer.java:121)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:351)
	at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:319)
	at org.apache.hadoop.hbase.http.HttpServer.openListeners(HttpServer.java:1120)
	... 6 more
{noformat}
Bug: Build automation using Yetus pre-releases shouldn't assume test-patch runs directly from a src checkout
Status: Open | Priority: Minor | Resolution: 
Created: 26/Feb/20 17:48

HBASE-23873 reports that several places where CI tools allow for running with a Yetus that is not a release build are broken. The gist from that ticket is that at some point, Yetus restructured its {{precommit/src}} module and now paths are broken. In a discussion, [~busbey] mentioned that we should not assume that test-patch can be run directly from a source checkout and probably the automation should instead depend on (or perform) a build of the specified Yetus sources before consuming them. Thus this ticket documents the issue.
Bug: Remove deprecated createTableDescriptor(String) from HBaseTestingUtility
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 31/Jan/20 08:36
Affects Version/s: 3.0.0-alpha-1

{{createTableDescriptor(String)}} in {{HBaseTestingUtility}} was deprecated back in 2.0.0 and should be removed for 3.0.0.
Bug: Addition to Supporting projects page
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Jan/20 06:28

At [Flipkart|https://flipkart.com/], we are using a light-weight ORM wrapper on top of hbase-client: [hbase-orm|https://github.com/flipkart-incubator/hbase-orm] (open source, Apache 2.0 license)

It helps Java applications interact with HBase in an object-oriented manner, by encapsulating {{Get}}, {{Put}}, {{Delete}}, {{Append}}, {{Increment}} and other classes in hbase-client.
  
 It's published on Maven Central:
 [https://search.maven.org/search?q=g:com.flipkart%20AND%20a:hbase-object-mapper&core=gav]

Kindly list this as supporting project. PR to follow.
Bug: unable to communicate with localhost when setting up Kerberos-related tests
Status: Open | Priority: Minor | Resolution: 
Created: 29/Jan/20 18:40

[~ndimiduk] gave an ask over on HBASE-23760 to change some of the Hadoop-level configuration properties around secure cluster setup from localhost to 127.0.0.1. He and [~bharathv] have been chasing some issues with ZooKeeper and not having a resolution of localhost to 127.0.0.1.

Before I start making a change, how sure are we that this is an issue? Assuming that it's the nightlies that we see these on, how about we make a change to increase the krb5 and spnego debugging to see if we aren't resolving names properly?

There might be a debug property for DNS lookups in Java too.... maybe?
Bug: TestSecureRESTServer fails due to hostname mismatch
Status: Open | Priority: Minor | Resolution: 
Created: 29/Jan/20 22:54
Affects Version/s: 2.3.0

Above test fails reliably in a simpleVagrant/VirtualBox Ubuntu vm.

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.005 s <<< FAILURE! - in org.apache.hadoop.hbase.rest.TestSecureRESTServer
org.apache.hadoop.hbase.rest.TestSecureRESTServer  Time elapsed: 0.001 s  <<< ERROR!
java.io.IOException: Failed on local exception: java.io.IOException: Couldn't setup connection for hbase/localhost@EXAMPLE.COM to localhost/127.0.0.1:45719; Host Details : local host is: "bionic/10.0.2.15"; destination host is: "localhost":45719;
        at org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:193)
Caused by: java.io.IOException: Couldn't setup connection for hbase/localhost@EXAMPLE.COM to localhost/127.0.0.1:45719
        at org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:193)
Caused by: javax.security.sasl.SaslException: GSS initiate failed
        at org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:193)
Caused by: org.ietf.jgss.GSSException: No valid credentials provided (Mechanism level: Message stream modified (41) - Message stream modified)
        at org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:193)
Caused by: sun.security.krb5.KrbException: Message stream modified (41) - Message stream modified
        at org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:193)
Caused by: sun.security.krb5.Asn1Exception: Identifier doesn't match expected value (906)
        at org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:193)
{noformat}
Bug: [DOC] Fix the maths on the section explaining call queue tuning options
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 05/Feb/20 21:40

Section *"121.11. Tuning callQueue Options"* from the RefGuide has some mismatches when explaining the percentages applied by different values set to _hbase.ipc.server.callqueue.read.ratio_ and _hbase.ipc.server.callqueue.scan.ratio,_ respectively, such as:

??A value of {{.3}} {color:#ff0000}uses 30% of the queues for reading and 60% for writing{color}. Given a value of {{10}} for {{hbase.ipc.server.num.callqueue}}, 3 queues would be used for reads and 7 for writes.??

Should be:

??A value of {{.3}} {color:#00875a}uses 30% of the queues for reading and 70% for writing.{color} Given a value of {{10}} for {{hbase.ipc.server.num.callqueue}}, 3 queues would be used for reads and 7 for writes.??
Bug: Remove deprecated createLocalHTU(Configuration) from HBaseTestingUtility
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jan/20 19:17
Affects Version/s: 3.0.0-alpha-1

{{createLocalHTU(Configuration)}} in {{HBaseTestingUtility}} was deprecated back in 2.0.0 and should be removed for 3.0.0.
Bug: Add 'new on release line report' for git/jira audit tool
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 29/Jan/20 01:01

Codify building the summary of what's new on a release line branch (i.e., {{branch-2}}), but not yet released on earlier release branches of that line.

Builds a cvs report that looks like [https://home.apache.org/~ndimiduk/new_for_branch-2.csv|https://home.apache.org/~ndimiduk/new_for_branch-2.csv]
Bug: Remove deprecated createTableDescriptor(String, int, int, int, KeepDeletedCells) from HBaseTestingUtility
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jan/20 19:42
Affects Version/s: 3.0.0-alpha-1

{{createTableDescriptor(String, int, int, int, KeepDeletedCells)}} in {{HBaseTestingUtility}} was deprecated back in 2.0.0 and should be removed for 3.0.0.