av9ash/GitBugs huggingface dataset:
Bug: Create table very slowly if there are multi regions
Status: Open | Priority: Blocker | Resolution: 
Created: 28/Oct/20 10:10
Affects Version/s: 2.2.6

Run the same UT TestRegionReplicaFailover on my local PC, mvn clean test -Dtest=TestRegionReplicaFailover, branch-2.2 takes 8 mins but branch-2.3 only needs 2 mins. 
  
 I found the problem is related to procedure schedule. See the below log:
 2020-10-21 13:52:28,097 INFO  [PEWorker-1] procedure2.ProcedureExecutor(1427): Finished pid=296, ppid=45, state=SUCCESS; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure in 1.6250sec
 2020-10-21 13:52:28,538 INFO  [PEWorker-3] procedure2.ProcedureExecutor(1427): Finished pid=45, ppid=20, state=SUCCESS; TransitRegionStateProcedure table=testLotsOfRegionRepli2, region=50703895da3cb8c942d3197600d549bc, ASSIGN in 59.4330sec
  
 The real assign procedure only cost 1.6 seconds but the TransitRegionStateProcedure cost 59.4 seconds. The pid=45 procedure was initialized at 2020-10-21 13:51:28,666. It was added to TableQueue at 2020-10-21 13:51:28,789. But took xlock to run at 2020-10-21 13:52:24,761. See the below log:
 {color:#ff0000}2020-10-21 13:51:28,789{color} DEBUG [PEWorker-4] procedure.MasterProcedureScheduler(352): Add TableQueue(testLotsOfRegionRepli2, xlock=true (20) sharedLock=0 size=25) to run queue because: pid=45, ppid=20, state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE; TransitRegionStateProcedure table=testLotsOfRegionRepli2, region=50703895da3cb8c942d3197600d549bc, ASSIGN has the excusive lock access
 {color:#ff0000}2020-10-21 13:52:24,761{color} INFO  [PEWorker-2] procedure.MasterProcedureScheduler(737): Took xlock for pid=45, ppid=20, state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE; TransitRegionStateProcedure table=testLotsOfRegionRepli2, region=50703895da3cb8c942d3197600d549bc, ASSIGN
  
 But when I tried this UT on another PC, it only cost 2 mins, which is the same with branch-2.3. It is weird.
  
 Marked this as blocker for release 2.2.7.

 

If you are interested for this, please run "mvn clean test -Dtest=TestRegionReplicaFailover" and comment the cost time here. Thanks.
Bug: TestMasterRegionOnTwoFileSystems is failing after HBASE-25065
Status: Resolved | Priority: Blocker | Resolution: Fixed
Created: 14/Oct/20 10:21
Affects Version/s: 2.4.0

After HBASE-25065, we are having a test case failure with TestMasterRegionOnTwoFileSystems. 
The reason is that we manually trigger a WAL roll on the master region. As part of the WAL roll we expect the Master region's WAL will also be moved from region oldWAL dir to the global oldWAL directory. This happens after afterRoll() method in AbstractWALRoller. 
Since  now the WAL archival is asynchronous the afterRoll() method does not find any WAL file to be moved in the local region oldWAL dir. So the movement to global oldWAL dir does not happen. 
The test case checks for the file in the oldWAL dir and since it is not found the test timesout. WE need a way to fix this.
Bug: about hbase introduced fasterxml‘s jackson versions and vulnerabilities 
Status: Resolved | Priority: Blocker | Resolution: Duplicate
Created: 22/Oct/20 10:40

a lot of hbase component use htrace-core4, this htrace-core4 shaded fasterxml jackson(version 2.4.0)

[INFO] | +- org.apache.hbase.thirdparty:hbase-shaded-miscellaneous:jar:2.2.1:compile
 [INFO] | +- org.slf4j:slf4j-api:jar:1.7.29:compile
 [INFO] | +- commons-io:commons-io:jar:2.6:compile
 [INFO] | +- {color:#ff0000}org.apache.htrace:htrace-core4:jar:4.2.0-incubating:compile{color}
 [INFO] | +- org.apache.commons:commons-crypto:jar:1.0.0:compile
 [INFO] | +- com.github.stephenc.findbugs:findbugs-annotations:jar:1.3.9-1:compile
 [INFO] | +- log4j:log4j:jar:1.2.17:compile
 [INFO] | - org.apache.yetus:audience-annotations:jar:0.5.0:compile

 

as you known fasterxml  jackson component is frequently coming out new vulnerabilities, like   CVE-2016-7051、CVE-2016-3720、CVE-2018-5968、CVE-2018-11307、CVE-2018-7489、CVE-2019-14893、CVE-2019-14379、CVE-2020-14195、CVE-2020-14061、CVE-2020-8840、CVE-2019-14540、CVE-2020-10968、CVE-2020-11619、CVE-2019-17531、CVE-2019-16943、CVE-2020-14062、CVE-2020-14060、CVE-2020-11111、CVE-2019-16942、CVE-2020-9546、CVE-2020-9548、CVE-2019-12384、CVE-2020-10673、CVE-2020-24750、CVE-2019-16335、CVE-2019-14439、CVE-2020-10969、CVE-2020-11112、CVE-2019-12086、CVE-2019-20330、CVE-2019-17267、CVE-2020-9547、CVE-2020-11113、CVE-2020-10672、CVE-2020-11620、CVE-2020-24616、CVE-2018-19362、CVE-2018-19361、CVE-2018-19360、CVE-2018-14721、CVE-2018-14720、CVE-2018-14719、CVE-2018-14718、CVE-2018-1000873、CVE-2017-7525、CVE-2017-17485、CVE-2017-15095，CVE-2019-12814

htrace-core4 is closed 4 years ago,  what about this component's vulnerabilities, did hbase have plan to do with this？
Bug: c++库编译不通过
Status: Open | Priority: Critical | Resolution: 
Created: 26/Dec/20 08:25

我用自己在msys下编译了thrift0.13.0版本的lib库和compiler，用生成的compiler用当前github上最新的thrift2中的hbase.thrift文件生成了c++连接hbase的代码，然后在windows下用QtCreator建立了一个测试工程尝试编译，出现了两个错误：

1. 
{code:java}
struct TKeepDeletedCells
{
    enum type { 
      FALSE = 0,  //此处报错：error: expected identifier before numeric constant
      TRUE = 1, 
      TTL = 2 };
};{code}
错误堆栈：
{code:java}
In file included from D:/Apps/Qt/Qt5.12.9/Tools/mingw730_64/x86_64-w64-mingw32/include/windef.h:8:0,
                 from D:/Apps/Qt/Qt5.12.9/Tools/mingw730_64/x86_64-w64-mingw32/include/windows.h:69,
                 from D:/Apps/Qt/Qt5.12.9/Tools/mingw730_64/x86_64-w64-mingw32/include/winsock2.h:23,
                 from ..\..\TestBoost\include/thrift/transport/PlatformSocket.h:26,
                 from ..\..\TestBoost\include/thrift/Thrift.h:23,
                 from ..\..\TestBoost\hbase-thrift2-13\Hbase_types.h:12,
                 from ..\..\TestBoost\hbase-thrift2-13\Hbase_constants.h:10,
                 from ..\..\TestBoost\hbase-thrift2-13\Hbase_constants.cpp:7:
..\..\TestBoost\hbase-thrift2-13\Hbase_types.h:151:17: error: expected identifier before numeric constant
     enum type { FALSE = 0, TRUE = 1, TTL = 2 };
                 ^{code}
错误原因：windef.h引用了头文件minwindef.h，其中对TRUE，FALSE进行了宏定义，导致此处不是一个有效的变量名
{code:java}
#ifndef FALSE
#define FALSE 0
#endif

#ifndef TRUE
#define TRUE 1
#endif{code}
我在struct TKeepDeletedCells前增加了
{code:java}
#UNDEF TRUE
#UNDEF FALSE{code}
规避该问题

2. D:\Apps\Qt\Qt5.12.9\Tools\mingw730_64\lib\gcc\x86_64-w64-mingw32\7.3.0\include\c++\bits\stl_function.h:386: error: undefined reference to `apache::hadoop::hbase::thrift2::TServerName::operator<(apache::hadoop::hbase::thrift2::TServerName const&) const'

thrift生成的TServerName定义只给出了操作符定义，并未实现

bool operator<(const TServerName &) const;

导致调用报错，不过我并未找到在哪里调用的<操作符，不过TServerName被放到了std:vector中，可能是vector中的函数调用了它

我增加了该操作符的实现就可以编译通过了
{code:java}
bool operator<(const TServerName &rhs) const { return startCode < rhs.startCode; };
{code}
Bug: Nightly build setup failure with Ruby version
Status: Resolved | Priority: Critical | Resolution: Resolved
Created: 18/Nov/20 15:23
Affects Version/s: 1.7.0

Nightly builds are failing on branch-2.2 and branch-1 in Docker setup phase.

{noformat}
Step 28/33 : RUN gem install rubocop:'<= 0.81'
 ---> Running in ca2c6ed8ee8a
Building native extensions.  This could take a while...
ERROR:  Error installing rubocop:
	parallel requires Ruby version >= 2.5.
Successfully installed jaro_winkler-1.5.4
The command '/bin/sh -c gem install rubocop:'<= 0.81'' returned a non-zero code: 1
ERROR: Docker failed to build yetus/hbase:e5c0a9422c.
{noformat}
Bug: Old WALs archive fails in procedure based WAL split
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 25/Dec/20 07:06
Affects Version/s: 2.2.6

If 'hbase.wal.dir' and 'hbase.rootdir' are configured to different filesystem, SplitWALRemoteProcedure archived split WAL failed since SplitWALManager using wrong fs instance. SplitWALManager should use WAL corresponding fs instance.

Steps to Reproduce:
 * Configure 'hbase.wal.dir' and 'hbase.rootdir' so that they point to different fs instances.
 * Start HBase with multiple RS. 
 * Create a couple of tables and some rows in them so that the RSs get assigned with some regions. 
 * Take any RS with non-zero number of regions offline. 
 * Check master logs for "Wrong FS" error as shown in the screenshot attached.
Bug: postScannerFilterRow impacts Scan performance a lot in HBase 2.x
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 12/Nov/20 19:18

In our test we observed Scan performance is degraded by more than 60% in HBase-2.x as compared to 1.3.x.  As per the flamegraph report, RS spent 31% of the time in postScannerFilterRow, however the coprocessors (AccessController, VisibilityController & ConstraintProcessor) does nothing in that hook.

HBASE-14489 added the logic to avoid the call to postScannerFilterRow when not needed which is not working as expected in HBase 2.x. AccessController, VisibilityController & ConstraintProcessor override the postScannerFilterRow with dummy (same as RegionObserver) implementation, so RegionCoprocessorHost.hasCustomPostScannerFilterRow will be TRUE and call the hook for all configured CPs while processing each row .  Suppose we have configured 5 region CPs and there are 1 M rows in table, then there will be 1 * 5 M dummy call to postScannerFilterRow during whole table scan.
We need to remove postScannerFilterRow hook from these CPs as these are not doing anything.

Another problem is in RegionCoprocessorHost.hasCustomPostScannerFilterRow init logic, currently it is always TRUE even though we remove postScannerFilterRow hook from AccessController, VisibilityController & ConstraintProcessor, because we are finding  postScannerFilterRow until  it is found (we look in configured CP's super class also) or clazz is NULL.

https://github.com/apache/hbase/blob/035c192eb665469ce0c071db86c78f4a873c123b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java#L301

Supper class of Object (super class of AccessController) will be NULL, so RegionCoprocessorHost.hasCustomPostScannerFilterRow will be set as TRUE
https://github.com/apache/hbase/blob/035c192eb665469ce0c071db86c78f4a873c123b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java#L279
Bug: add security check for some APIs in RSRpcServices
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 24/Dec/20 02:11

 
||API||Severity||symptom||
|clearRegionBlockCache|Severe|The API will call LruBlockCache.evictBlocksByHfileName, 
 who is declared as an expensive operation(see its comments), thus non-amin may result Dos|
|clearSlowLogsResponses|Normal|clears queue records from ringbuffer|
|updateConfiguration|Normal|non-admin user can make RS reload configutation from disk by this API. |
|updateRegionFavoredNodesMapping|Normal|Non-admin user can change the region's best storage location by this api|
|stopServer|low|stopServer on RS is slient, which make client think he/she success shutdown RS. 
 Add preRpcCheck ont only make client receive the failed message, 
 but also prevent the non-admin user stop the RS, 
 even the hbase.coprocessor.regionserver.classes are not configured.|
Bug: list_regions make potential sensitive information disclosure
Status: Open | Priority: Critical | Resolution: 
Created: 18/Dec/20 05:01

I found that I can get other users' region information which is not expected.
  
 For example i create a table as sysadmin, then I can read the region information as user1.
 !image-2020-12-18-13-00-20-126.png!
  
 I have found that list_regions is introduced by https://issues.apache.org/jira/browse/HBASE-14925

 

we can also get the region info by rest  

 

!image-2020-12-18-13-07-00-777.png!

 
 i think if we expose more informaiton, we will be in more danger case, and even be attacked by others.
Bug: Legacy comparator in Hfile trailer will fail to load
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 09/Dec/20 13:13
Affects Version/s: 2.3.2

HBASE-24968 moved MetaCellComparator out from CellComparatorImpl to avoid the deadlock issue. But this introduced compatibility issue, old hfile with comparator class as "org.apache.hadoop.hbase.CellComparator$MetaCellComparator" will fail to open due to ClassNotFoundException.

Also we should also handle the case when comparator class is "org.apache.hadoop.hbase.CellComparatorImpl$MetaCellComparator", which was case before HBASE-24968.
Bug: Master fails to initialize when creating rs group table
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 08/Nov/20 03:37

Saw this when setup TestRSGroupsKillRS

{noformat}
2020-11-07 16:29:54,565 ERROR [master/e476f4f509a7:0:becomeActiveMaster] helpers.MarkerIgnoringBase(159): Failed to become active master
java.lang.AssertionError
	at org.apache.hadoop.hbase.master.assignment.RegionStateNode.setProcedure(RegionStateNode.java:198)
	at org.apache.hadoop.hbase.master.assignment.AssignmentManager.createAssignProcedure(AssignmentManager.java:647)
	at org.apache.hadoop.hbase.master.assignment.AssignmentManager.lambda$null$6(AssignmentManager.java:878)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272)
	at java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1699)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:546)
	at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:505)
	at org.apache.hadoop.hbase.master.assignment.AssignmentManager.createAssignProcedures(AssignmentManager.java:879)
	at org.apache.hadoop.hbase.master.assignment.AssignmentManager.createRoundRobinAssignProcedures(AssignmentManager.java:759)
	at org.apache.hadoop.hbase.master.assignment.AssignmentManager.createRoundRobinAssignProcedures(AssignmentManager.java:775)
	at org.apache.hadoop.hbase.master.assignment.AssignmentManager.processOfflineRegions(AssignmentManager.java:1513)
	at org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:1012)
	at org.apache.hadoop.hbase.master.HMaster.startActiveMasterManager(HMaster.java:2116)
	at org.apache.hadoop.hbase.master.HMaster.lambda$run$0(HMaster.java:515)
	at java.lang.Thread.run(Thread.java:748)
{noformat}
Bug: allow specifying binary row key range to pre-split regions
Status: Open | Priority: Major | Resolution: 
Created: 04/Dec/20 04:13

Currently, spark hbase connector use `String` to specify regionStart and regionEnd, but we often have serialized binary row key,  I made a little patch at [https://github.com/apache/hbase-connectors/pull/72/files] to always treat the `String` in ISO_8859_1, so we can put raw bytes into the String object and get it unchanged.

This has a drawback,  if your row key is really Unicode strings beyond ISO_8859_1 charset, you should convert it to UTF-8 encoded bytes and then encapsulate it in ISO_8859_1 string. This is a limitation of Spark option interface which allows only string to string map.
{code:java}
import java.nio.charset.StandardCharsets;

df.write()
  .format("org.apache.hadoop.hbase.spark")
  .option(HBaseTableCatalog.tableCatalog(), catalog)
  .option(HBaseTableCatalog.newTable(), 5)
  .option(HBaseTableCatalog.regionStart(), new String("你好".getBytes(StandardCharsets.UTF_8), StandardCharsets.ISO_8859_1))
  .option(HBaseTableCatalog.regionEnd(), new String("世界".getBytes(StandardCharsets.UTF_8), StandardCharsets.ISO_8859_1))
  .mode(SaveMode.Append)
  .save();
{code}
Bug: Update create-release mvn in Dockerfile; its 3.6.0; make it 3.6.3
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 23/Dec/20 02:01

Having trouble running RM builds from gcp. Downloads of artifacts are having connection reset. Apparently mvn 3.6.1 gets a better http wagon downloader. Doesn't seem to help in this particular case but let me get this in anyways.
Bug: Protobuf Mesage Incompatibility Detector
Status: Open | Priority: Major | Resolution: 
Created: 29/Nov/20 04:37
Affects Version/s: 2.2.6

Regarding the issue HBASE-25238. caused by the incompatibility of protobuf message, we have created a static checker which keeps track of the proto file change, and detect potential incompatibility:
 # Add/delete required field, which is exactly the case reported in HBASE-25238.
 # The tag number of a field has been changed, as described in HDFS-9788. Also, the [protobuf guidelines |https://developers.google.com/protocol-buffers/docs/proto]suggests _each field in the message definition has a *unique number*. These numbers are used to identify your fields in the [message binary format|https://developers.google.com/protocol-buffers/docs/encoding], and should not be changed once your message type is in use_. 
 # A  required field has been changed to optional, or an optional field has been changed to required. According to the guidelines in [protobuf official website|https://developers.google.com/protocol-buffers/docs/proto], _*Required Is Forever* You should be very careful about marking fields as {{required}}. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field - old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead._

We have applied our checker on the frequently maintained HBASE versions: rel/1.4.3, rel/1.6.0, rel/2.2.6, rel/2.3.3, and master, and we found 37 potential problems as attached, which includes the one found in HBASE-25238.
Bug: Support splitting a region into N parts at a time
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 04/Nov/20 10:13

In the current reference file format, only one parent region split into two references can be recorded. At this time, if you want to continue splitting the daughter region, you must wait until the majorCompaction is over and the reference file is deleted before you can continue to split the region.

If the reference file can point to other refenrence files, which data has not been moved from the parentRegion to the region under the corresponding folder, thereby establishing a multi-level reference. At this time, a tree structure is formed. Only the root contains physical data, and the region on the leaf node region is serving.
Bug: There is no limit on the table name length when creating a table
Status: Patch Available | Priority: Major | Resolution: 
Created: 22/Dec/20 04:00
Affects Version/s: 2.2.3

It occurs Exeception(ERROR：java.util.concurrent.ExecutionExceptionjava.io.IOExpcetionException in createDir) because of 8000 bytes length limits on HDFS directory name if the length of HBase table name misses validation when creating.

So,we decide to verify the length of table name when creating a table.IllegalArgumentExcetion will be thrown when length is larger than 8000 bytes.
Bug: Super Split Meta
Status: Open | Priority: Major | Resolution: 
Created: 10/Dec/20 20:22

Currently, the hbase:meta Table is made of one Region only. It is not splittable. We would like to make it so the hbase:meta table can be split just as we for user-space tables as they grow in size.

Why split the hbase:meta table?

{quote}A single Region _hbase:meta_ Table hotspots as cluster size grows. At extreme, hotspotting brings on special-casing with deploys dedicating nodes solely to the hosting of the single _hbase:meta_ Region to better carry the higher load (but also to isolate _hbase:meta_ if heavily trafficked neighbor Regions). Splitting, currently disallowed, will enable distributing the _hbase:meta_ Table Regions, and thereby load, across the cluster. A splittable _hbase:meta_ table will also alleviate concerns enlarging the _hbase:meta_ table whether by adding more meta data per Region entry -- e.g. keeping the list of Region HFiles in the _hbase:meta_ table -- or running with more, smaller Regions rather than a few large Regions.
{quote}

This is not the first issue to concern itself with meta splitting (HBASE-11288, HBASE-24950). By aggreement. -- see the base of HBASE-11288 -- this issue supplants all previous JIRAs and design efforts. It is a reset. We start by listing requirements in the attached Super Split Meta Design.
Bug: Add a cost function to move the daughter regions of a recent split to different region servers 
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 27/Oct/20 17:20

In HBase, hotspot regions are easily formed whenever there is skew and there is high write volume. Few regions grow really fast which also becomes the bottleneck on the few region servers. 
It would be beneficial to add a cost function to move the regions after the split to differetn region servers. In this way the writes to hot key range will be distributed to multiple region servers.
Bug: s390x support for HBase CI
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 16/Oct/20 10:48

Hi All,
As I understand that currently CI available for HBase ( to validate any code updates ) is : https://ci-hadoop.apache.org/job/HBase/ and as can be seen most of the deployment here is on amd64 and ppc64le. 
Wanted to know your views/comments/suggestions for extending CI of HBase on s390x .
1) If the community will be willing to add - vm's/slaves ( s390x based ) to their current above CI.
2) Use an externally hosted jenkins CI - for running HBase build on s390x and link the results of the build to the above CI.
Please let me know your thoughts.
Regards,
Aditi
Bug: [branch-1] Consume Guava from hbase-thirdparty hbase-shaded-miscellaneous
Status: Resolved | Priority: Major | Resolution: Won't Fix
Created: 19/Nov/20 18:05

We are again having classpath versioning issues related to Guava in our branch-1 based application.

Hadoop 3, HBase 2, Phoenix 5, and other projects deal with Guava cross-version incompatibilities, as they manifest on a combined classpath with other components, via shading.

I propose to do a global search and replace of all direct uses of Guava in our branch-1 code base and refer to Guava as provided in hbase-thirdparty's hbase-shaded-miscellaneous. This will protect HBase branch-1 from Guava cross-version vagaries just like the same technique protects branch-2 and branch-2 based releases.

There are a couple of Public or LimitedPrivate interfaces that incorporate Guava's HostAndPort and Service that will be indirectly impacted. We are about to release a new minor branch-1 version, 1.7.0, and this would be a great opportunity to introduce this kind of change in a manner consistent with semantic versioning and our compatibility policies.
Bug: 'dfs.client.read.shortcircuit' should not be set in hbase-default.xml
Status: Closed | Priority: Major | Resolution: Fixed
Created: 28/Dec/20 08:18
Affects Version/s: 2.0.1

I think this parameter is not suitable for in hbase-default.xml, because in this case, HDFS explicitly set to "dfs.client.read.shortcircuit=true", hbase rely on HDFS configuration, the parameters in hbase service still is false.Must be explicitly in hbase-site.xml is set to "dfs.client.read.shortcircuit=true" to take effect.The same goes for the parameter 'dfs.domain.socket.path', which is already covered in the specific change.