av9ash/GitBugs huggingface dataset:
Bug: Introduce a config to enable setting normalizer target region count through hbase site.
Status: Open | Priority: Major | Resolution: 
Created: 01/Mar/22 11:03
Affects Version/s: 1.7.1

Currently, we can define NORMALIZER_TARGET_REGION_COUNT in table descriptors. I am thinking of introducing a global property through hbase-site so we don't need to set it at each level but just add the property and that would be considered a default value. If we want to override this value we can always use htable descriptor for selected tables.

priority of configs (priority decreases as we move down)

NORMALIZER_TARGET_REGION_COUNT

hbase.normalizer.target_region_count
Bug: The ByteBuffer of metadata in RAMQueueEntry in BucketCache could be reused.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jan/22 14:39

Currently, the process to write HFileBlocks into IOEngine in BucketCache is:

{code:java}
 if (data instanceof HFileBlock) {
          // If an instance of HFileBlock, save on some allocations.
          HFileBlock block = (HFileBlock) data;
          ByteBuff sliceBuf = block.getBufferReadOnly();
          ByteBuffer metadata = block.getMetaData();
          ioEngine.write(sliceBuf, offset);
          ioEngine.write(metadata, offset + len - metadata.limit());
        }
{code}

The getMetaData() function in HFileBlock is:

{code:java}
public ByteBuffer getMetaData() {
    ByteBuffer bb = ByteBuffer.allocate(BLOCK_METADATA_SPACE);
    bb = addMetaData(bb, true);
    bb.flip();
    return bb;
  }
{code}
It will allocate new ByteBuffer every time.
We could reuse a local variable of WriterThread to reduce the new allocation of this small piece ByteBuffer.
Reasons:
1. In a WriterThread, blocks in doDrain() function are written into IOEngine sequentially, there is no multi-threads problem.
2. After IOEngine.write() function, the data in metadata ByteBuffer has been transferred into ByteArray (ByteBufferIOEngine) or FileChannel (FileIOEngine) safely. The lifecycle of it is within the if statement above. So that it could be cleared and reused by the next block's writing process.
Bug: Update create-release template to link to publicly visible resources
Status: Open | Priority: Major | Resolution: 
Created: 24/Feb/22 14:06

Per discussion on [0], let us update the template used by release managers to link to resources that are not gated by any type of authentication.

[0]: https://lists.apache.org/thread/148xwk7vsgsncbomqqrzh477rlr7smdr
Bug: Setback occurs to AsyncFSWAL#highestProcessedAppendTxid and then IllegalArgumentException
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 21/Feb/22 03:54
Affects Version/s: 2.4.9

The consumer thread in AsyncFSWAL crashed by IllegalArgumentException, stack trace is as follows,
{code:java}
Exception in thread "XXXX" java.lang.IllegalArgumentException: fromKey > toKey
        at java.util.TreeMap$NavigableSubMap.<init>(TreeMap.java:1368)
        at java.util.TreeMap$AscendingSubMap.<init>(TreeMap.java:1855)
        at java.util.TreeMap.subMap(TreeMap.java:913)
        at java.util.TreeSet.subSet(TreeSet.java:325)
        at java.util.TreeSet.subSet(TreeSet.java:361)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.isHsync(AsyncFSWAL.java:375)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.sync(AsyncFSWAL.java:392)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.appendAndSync(AsyncFSWAL.java:504)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.consume(AsyncFSWAL.java:565)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Exception in thread "XXXX" java.lang.IllegalArgumentException: fromKey > toKey
        at java.util.TreeMap$NavigableSubMap.<init>(TreeMap.java:1368)
        at java.util.TreeMap$AscendingSubMap.<init>(TreeMap.java:1855)
        at java.util.TreeMap.subMap(TreeMap.java:913)
        at java.util.TreeSet.subSet(TreeSet.java:325)
        at java.util.TreeSet.subSet(TreeSet.java:361)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.isHsync(AsyncFSWAL.java:375)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.sync(AsyncFSWAL.java:392)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.appendAndSync(AsyncFSWAL.java:504)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.consume(AsyncFSWAL.java:565)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745) {code}
Bug: hbase thrift2 FilterString not working
Status: Open | Priority: Major | Resolution: 
Created: 15/Feb/22 09:00
Affects Version/s: 2.4.9

I am trying to connect hbase by thrift2 golang client.

Everything works well but the filterString field. No matter what value I set (just simply convert from string to []byte) it doesn't work and return an empty result.

And I had tried the thrift service of the old version and it worked. Is there some hint trick to generate the filterString []byte in thrift2?
Bug: remove disabled hbase jobs from ci-hadoop
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/Feb/22 17:32

There are a bunch of disabled jobs on ci-hadoop from us cautiously moving to ci-hbase. Delete them all once we're confident that things are moved over to ci-hbase enough that we are going to handle future problems by fixing them in-place on ci-hbase rather than rolling back to running on ci-hadoop.
Bug: Comparator of NOT_EQUAL NULL is invalid for checkAndMutate
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Feb/22 04:18
Affects Version/s: 1.8.0

 In server side, checkAndMutate ignores CompareOperator for null or empty comparator value, but NOT_EQUAL should be treated specially.

The check logic in HRegion#checkAndMutateInternal is as follows,
{code:java}
boolean valueIsNull =
  comparator.getValue() == null || comparator.getValue().length == 0;
if (result.isEmpty() && valueIsNull) {
  matches = true;
} else if (result.size() > 0 && result.get(0).getValueLength() == 0 && valueIsNull) {
  matches = true;
  cellTs = result.get(0).getTimestamp();
} else if (result.size() == 1 && !valueIsNull) {
  Cell kv = result.get(0);
  cellTs = kv.getTimestamp();
  int compareResult = PrivateCellUtil.compareValue(kv, comparator);
  matches = matches(op, compareResult);
}{code}
For current logics, here are some  counter examples(Comparator value is set null),
 # result is null, operator is NOT_EQUAL, but matches is true;
 # result size >0, the value of the first cell is empty, operator is NOT_EQUAL, but matches is true;
 # result size is 1, operator is NOT_EQUAL, but matches is false;
Bug: HBase Thirdparty repo should have nightly for checking main repo tests on top of SNAPSHOT artifacts
Status: Open | Priority: Major | Resolution: 
Created: 16/Feb/22 15:06

We should have a nightly test that runs if there are changes to

* top level pom
* any of the hbase-shaded-* modules

That test should grab the current HEAD of a configurable branch of the main repo (which defaults to the repo's default branch, currently master) and then attempt a build + tests while setting {{hbase-thirdparty.version}} to the in-progress SNAPSHOT build. The test run should exclude the current set of flaky tests.
Bug: RegionReplicationSink.send set timeout for replicating meta edits error
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Feb/22 06:00
Affects Version/s: 3.0.0-alpha-3

HBASE-26539 introduce separate {{RegionReplicationSink.metaEditRpcTimeoutNs}} and {{RegionReplicationSink.metaEditOperationTimeoutNs}} for replicating meta edits, but seems in {{RegionReplicationSink.send}} set timeout is erroneous:
{code:java}
     if (hasMetaEdit) {
      rpcTimeoutNsToUse = rpcTimeoutNs;
      operationTimeoutNsToUse = operationTimeoutNs;
    } else {
      rpcTimeoutNsToUse = metaEditRpcTimeoutNs;
      operationTimeoutNsToUse = metaEditOperationTimeoutNs;
    }
{code}
Bug: Spurious compaction failures with file tracker
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 04/Jan/22 16:01

Noticed when running a basic {{{}hbase pe randomWrite{}}}, we'll see compactions failing at various points.

One example:
{noformat}
2022-01-03 17:41:18,319 ERROR [regionserver/localhost:16020-shortCompactions-0] regionserver.CompactSplit(670): Compaction failed region=TestTable,00000000000000000004054490,1641249249856.2dc7251c6eceb660b9c7bb0b587db913., storeName=2dc7251c6eceb660b9c7bb0b587db913/info0,       priority=6, startTime=1641249666161
java.io.IOException: Root-level entries already added in single-level mode
  at org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexWriter.writeSingleLevelIndex(HFileBlockIndex.java:1136)
  at org.apache.hadoop.hbase.io.hfile.CompoundBloomFilterWriter$MetaWriter.write(CompoundBloomFilterWriter.java:279)
  at org.apache.hadoop.hbase.io.hfile.HFileWriterImpl$1.writeToBlock(HFileWriterImpl.java:713)
  at org.apache.hadoop.hbase.io.hfile.HFileBlock$Writer.writeBlock(HFileBlock.java:1205)
  at org.apache.hadoop.hbase.io.hfile.HFileWriterImpl.close(HFileWriterImpl.java:660)
  at org.apache.hadoop.hbase.regionserver.StoreFileWriter.close(StoreFileWriter.java:377)
  at org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.commitWriter(DefaultCompactor.java:70)
  at org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:386)
  at org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:62)
  at org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:125)
  at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1141)
  at org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2388)
  at org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:654)
  at org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:697)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)  {noformat}
This isn't a super-critical issue because compactions will be retried automatically and they appear to eventually succeed. However, when the max storefiles limit is reaching, this does cause ingest to hang (as I was doing with my modest configuration).

We had seen a similar kind of problem in our testing when backporting to HBase 2.4 (not upstream as the decision was to not do this) which we eventually tracked down to a bad merge-conflict resolution to the new HFile Cleaner. However, initial investigations don't have the same exact problem.

It seems that we have some kind of generic race condition. Would be good to add more logging to catch this in the future (since we have two separate instances of this category of bug already).
Bug: The replication batch size is too large and cannot be written to the standby cluster
Status: Open | Priority: Major | Resolution: 
Created: 25/Jan/22 11:59
Affects Version/s: 1.3.1

Recently, we met a replication failure and it cannot be recovered. The main reason is that the number of data records read from the wal during synchronization is not limited. In addition, the batch size is not limited when data is written to the peer cluster. As a result, the replication will be failed because of writing timeout. It is recommended that the number of records to be written  with a controllable range, for example, 2000 records, and can be modified through configuration.
Here are some log stacks
 !image-2022-01-25-19-59-39-118.png!
Bug: hbase regionserver keep on restarting in azure setup
Status: Open | Priority: Major | Resolution: 
Created: 22/Jan/22 13:52

hadoop hbase version 2.4.8
hadoop hdfs version 2.7.7

 

Hbase master and regionserver keep on restarting due to procedure.SplitWALProcedure: Failed to split wa

 

logs from master and regionserver attached
Bug: Performance regression in asyncwal 
Status: Open | Priority: Major | Resolution: 
Created: 07/Feb/22 14:00
Affects Version/s: 2.4.6

I've been doing load testing of hbase2, using hadoop 3.3.1 (client and server). Comparing the results to an identical cluster running hbase/hadoop cdh5.16.2 (hbase ~1.2.0, hadoop ~2.6.0). With a heavy write workload I would consistently see 99th percentile sync times of 5-6ms in cdh5, but 20-30ms in hbase2. Configuring hbase2 to use 'filesystem' wal provider mostly resolves this regression, resulting in latencies of 6-8ms. So still a little slower than cdh5, but much more reasonable.

Unfortunately I don't have a lot of flexibility in my environment to try various versions of hadoop. I didn't notice any exceptions or anything to indicate an API problem with hadoop 3.3.1, this may just be a general regression in the 2.x branch.

I briefly tried profiling wall clock time and the process was dominated by waiting in SyncFuture.get. I haven't dug deep enough into the code yet to know how to identify a bottleneck in whatever threads are responsible for completing those futures.

One thing to note, I tried enabling hbase.wal.async.use-shared-event-loop but noticed no difference.
Bug: [Flakey Tests] TestHBCKSCPUnknown.test fails while scheduling
Status: Open | Priority: Major | Resolution: 
Created: 19/Jan/22 18:46
Affects Version/s: 3.0.0-alpha-2

{noformat}
[ERROR] org.apache.hadoop.hbase.master.procedure.TestHBCKSCPUnknown.test  Time elapsed: 89.103 s  <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<0>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
	at org.apache.hadoop.hbase.master.procedure.TestHBCKSCPUnknown.scheduleHBCKSCP(TestHBCKSCPUnknown.java:51)
	at org.apache.hadoop.hbase.master.procedure.TestHBCKSCP.test(TestHBCKSCP.java:138)
	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:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.apache.hadoop.hbase.SystemExitRule$1.evaluate(SystemExitRule.java:38)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:748)
{noformat}
Bug: [Flakey Tests] TestThriftSpnegoHttpServer violates SystemExitRule
Status: Open | Priority: Major | Resolution: 
Created: 19/Jan/22 18:41
Affects Version/s: 3.0.0-alpha-2

{noformat}
[ERROR] org.apache.hadoop.hbase.thrift.TestThriftSpnegoHttpServer.testRunThriftServer  Time elapsed: 7.604 s  <<< ERROR!
org.apache.hadoop.hbase.SystemExitRule$SystemExitInTestException
	at org.apache.hadoop.hbase.TestSecurityManager.checkExit(TestSecurityManager.java:32)
	at java.lang.Runtime.exit(Runtime.java:107)
	at java.lang.System.exit(System.java:973)
	at org.apache.hadoop.hbase.thrift.ThriftServer$2.run(ThriftServer.java:873)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:360)
	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1709)
	at org.apache.hadoop.hbase.thrift.ThriftServer.run(ThriftServer.java:859)
	at org.apache.hadoop.hbase.thrift.ThriftServerRunner.run(ThriftServerRunner.java:55)
{noformat}
Bug: [Flakey Tests] TestBindExceptionHandling.testProtocolPortClash doesn't assert clean starting point
Status: Open | Priority: Major | Resolution: 
Created: 19/Jan/22 18:39
Affects Version/s: 3.0.0-alpha-2

Looks like the metrics subsystem is not being reset between test runs.

{noformat}
[ERROR] org.apache.hadoop.hbase.thrift.TestBindExceptionHandling.testProtocolPortClash  Time elapsed: 6.441 s  <<< ERROR!
org.apache.hadoop.metrics2.MetricsException: Metrics source Thrift,sub=ThriftOne already exists!
	at org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.newSourceName(DefaultMetricsSystem.java:152)
	at org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.sourceName(DefaultMetricsSystem.java:125)
	at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:229)
	at org.apache.hadoop.hbase.metrics.BaseSourceImpl.<init>(BaseSourceImpl.java:119)
	at org.apache.hadoop.hbase.metrics.ExceptionTrackingSourceImpl.<init>(ExceptionTrackingSourceImpl.java:47)
	at org.apache.hadoop.hbase.thrift.MetricsThriftServerSourceImpl.<init>(MetricsThriftServerSourceImpl.java:58)
	at org.apache.hadoop.hbase.thrift.MetricsThriftServerSourceFactoryImpl.createThriftOneSource(MetricsThriftServerSourceFactoryImpl.java:42)
	at org.apache.hadoop.hbase.thrift.ThriftMetrics.<init>(ThriftMetrics.java:77)
	at org.apache.hadoop.hbase.thrift.ThriftServer.createThriftMetrics(ThriftServer.java:206)
	at org.apache.hadoop.hbase.thrift.ThriftServer.setupParamters(ThriftServer.java:234)
	at org.apache.hadoop.hbase.thrift.ThriftServer.run(ThriftServer.java:853)
	at org.apache.hadoop.hbase.thrift.ThriftServerRunner.run(ThriftServerRunner.java:55)
{noformat}
Bug: [operator-tools] Provide a utility to detect and correct incorrect RegionInfo's in hbase:meta
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Jan/22 20:18

HBASE-23328 describes a problem in which the serialized RegionInfo in the value of hbase:meta cells have an encoded regionname which doesn't match the encoded region name in the rowkey for that cell.

This problem is normally harmless as assignment only consults the rowkey to get the encoded region name. However, this problem does break other HBCK2 tooling, like {{{}extraRegionsInMeta{}}}. 

Rather than try to update each tool to account for when this problem may be present, create a new tool which an operator can run to correct meta and then use any subsequent tools as originally intended.
Bug: Auto-disable setCacheBlocks when large scans are detected
Status: Open | Priority: Major | Resolution: 
Created: 05/Jan/22 20:00

Block cache churn is the biggest driver of GC issues, and also impacts the performance of clients which may rely on the cache. Ideally all users would remember to call setCacheBlocks(false) on their scan before doing a large scan, but it's also easy to forget. Operators may not realize this was a problem until a job is running which is quickly churning your cache.

It seems like we could provide a mechanism to detect large scans and transparently disable block caching on the server side when they might churn large portions of the cache.
Bug: MetricsStochasticBalancerSource metrics don't render in /jmx endpoint
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 08/Feb/22 16:29

The check in JSONBean [here|https://github.com/apache/hbase/blob/master/hbase-http/src/main/java/org/apache/hadoop/hbase/util/JSONBean.java#L266] causes the balancer cost metrics to be excluded from the {{/jmx}} endpoint. I think we should just remove the check for ":". I don't think including metrics with a colon in them poses any problem, since the strings are quoted. We removed this check in our cdh5 fork almost a year ago and have not seen any issues.

Alternatively we can fix the MetricsStochasticBalancerSource metrics to emit metrics that adhere to these filters, but I think that would be a backwards incompatible change since this is only a json rendering issue and people might be consuming JMX directly.
Bug: Fix CME in ReplicationSourceManager
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Mar/22 09:54
Affects Version/s: 2.4.10

Exception in thread "regionserver/hostname/ip:port" java.util.ConcurrentModificationException
        at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
        at java.util.ArrayList$Itr.next(ArrayList.java:851)
        at org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.join(ReplicationSourceManager.java:832)
        at org.apache.hadoop.hbase.replication.regionserver.Replication.join(Replication.java:162)
        at org.apache.hadoop.hbase.replication.regionserver.Replication.stopReplicationService(Replication.java:155)
        at org.apache.hadoop.hbase.regionserver.HRegionServer.stopServiceThreads(HRegionServer.java:2623)
        at org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1175)
        at java.lang.Thread.run(Thread.java:745)
Bug: Enhance StochasticLoadBalancer reported metrics and logs 
Status: Open | Priority: Minor | Resolution: 
Created: 03/Mar/22 20:21
Affects Version/s: 2.4.11

Sometimes we have noticeable skew in our hbase clusters but see the balancer cannot find a better plan to resolve this skew. When trying to reason about why the StochasticLoadBalancer is not taking action and appropriately tuning costs as needed, it is often hard to quickly reason about how the published metrics  and output in the logs correlate and impact the balancer actions. It is also sometimes hard to reason about how a cost like the move cost (which doesnt show up in imbalance and is a hidden cost against every move in calculating a new plan) might be impacting the balancer effectiveness. 

 

It would be nice to include some additional information like the sumMultiplier and overallCost in the logs as well as publish the weighted imbalance metrics and rename the cost metrics to CostFunctionPercentage. Also additional logging for the state of the cost functions when an improved plan cannot be found would also be helpful.
Bug: Shell suspended in background
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Feb/22 17:56

The hbase shell process hangs when running in the background with piped input.
{noformat}
$ cat command.sh
#!/bin/bash
echo "list" | bin/hbase shell > shell.out 2>&1 
$ ./command.sh &
[1] 62907
$ 
[1]  + 62907 suspended (tty output)  ./command.sh{noformat}
This regression was introduced with JRuby 9.1 -> 9.2 upgrade and the process hangs on this line: [https://github.com/apache/hbase/blob/master/hbase-shell/src/main/ruby/jar-bootstrap.rb#L41]