av9ash/GitBugs huggingface dataset:
Bug: Move NamedQueuePayload to hbase-common
Status: Resolved | Priority: Major | Resolution: Won't Fix
Created: 22/Apr/21 06:48

We use this class to record the balancer decision in LoadBalancer, so if we want to move LoadBalancer to hbae-balancer, we also need to move NamedQueueRecord related classes out of hbase-server. Since we use a system table to record, hbase-client will be a suitable place.

====== Update ======

A we depend on disruptor for NamedQueueRecord, I do not think it is a good idea to introduce this dependency to our client library. So let's just move the minimum classes to hbase-client or hbase-common instead of the whole namedqueues implementation.
Bug: Duplicate uploads for hbase-shaded-protobuf sources jar causing nexus deploy failure
Status: Open | Priority: Major | Resolution: 
Created: 10/Apr/21 15:54

There are two configurations in [pom.xml|https://github.com/apache/hbase-thirdparty/blob/master/hbase-shaded-protobuf/pom.xml] of hbase-shaded-protobuf that create the sources jar. Here is [one|https://github.com/apache/hbase-thirdparty/blob/ccc49e6a78a00e61fa49f1292ace2f8bde28c54e/hbase-shaded-protobuf/pom.xml#L150] in the maven-shade-plugin and [other|https://github.com/apache/hbase-thirdparty/blob/ccc49e6a78a00e61fa49f1292ace2f8bde28c54e/hbase-shaded-protobuf/pom.xml#L133] in maven-source-plugin(introduced in HBASE-18313)

After removing the one from maven-shade-plugin, viz. <createSourcesJar>true</createSourcesJar>, we are able to successfully deploy as it generates source jar only once.

 

Error stacktraces:

Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project hbase-shaded-protobuf: Failed to deploy artifacts: Could not transfer artifact org.apache.hbase.thirdparty:hbase-shaded-protobuf:jar:sources:3.5.1 from/to nexus ([https://nexus.xyz.com/nexus/content/repositories/hbase/):|https://nexus.soma.salesforce.com/nexus/content/repositories/salesforce-hbase/):] Transfer failed for [https://nexus.xyz.com/nexus/content/repositories/hbase/org/apache/hbase/thirdparty/hbase-shaded-protobuf/3.5.1/hbase-shaded-protobuf-3.5.1-sources.jar|https://nexus.soma.salesforce.com/nexus/content/repositories/salesforce-hbase/org/apache/hbase/thirdparty/hbase-shaded-protobuf/3.5.1-sfdc-1.0.3/hbase-shaded-protobuf-3.5.1-sfdc-1.0.3-sources.jar] 400 Bad Request -> [Help 1]

 

Build Commands: 

mvn org.codehaus.mojo:versions-maven-plugin:2.7:set -DgenerateBackupPoms=false -DoldVersion='\''*'\'' -DnewVersion='\''3.5.1'\'''

mvn -X -e -nsu clean deploy -DadditionalJOption=-Xdoclint:none -DskipTests
Bug: CandidateGenerator.getRandomIterationOrder is too slow on large cluster
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/21 13:15

Similar to HBASE-25759, it is just used to test whether we should skip calculation, but in production masterServices will never be null.

==========

Update, change the title of this issue for removing CandidateGenerator.getRandomIterationOrder as it is too slow which causes the CandidateGenerator.getRandomIterationOrder to fail when we remove the masterServices field in LocalityBasedCandidateGenerator. As this is the most important change in this issue so change the title of this issue.
Bug: Recommend Hadoop 3.x
Status: Open | Priority: Major | Resolution: 
Created: 14/Apr/21 01:41

We have this section in the hbase book:
{quote}
Hadoop 2.x is recommended.
Hadoop 2.x is faster and includes features, such as short-circuit reads (see Leveraging local data), which will help improve your HBase random read profile. Hadoop 2.x also includes important bug fixes that will improve your overall HBase experience. HBase does not support running with earlier versions of Hadoop. See the table below for requirements specific to different HBase versions.

Hadoop 3.x is still in early access releases and has not yet been sufficiently tested by the HBase community for production use cases.
{quote}

The Hadoop 2.x development is winding down. 2.10.x will be the last dev branch. On the contrary, we've got years of production users on Hadoop 3.x already so I think it's time to change our stance.
Bug: The master services field in LocalityBasedCostFunction is never used
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Apr/21 14:23

We just use it to test whether we should do the calculation.

But in fact, it should never be null when we arrive here. Maybe it is because in test we may skip setting the master services but I think we should just skip balancing in the balancer, not in the cost function.
Bug: Change default of `hbase.normalizer.merge.min_region_size.mb` to `0`
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 07/Apr/21 20:11
Affects Version/s: 2.5.0

The current default value is {{1}}, which means normalizer will leave regions of 0-1mb size hanging around. We should set this down to {{0}} so that these small regions go away by default. As I recall, the value was set as it is in order to prevent the normalizer from merging up regions immediately after an operator creates a pre-split table. IMHO, this use case is more than covered by these other configurations with their default values:
* {{hbase.normalizer.min.region.count=3}}
* {{hbase.normalizer.merge.min_region_age.days=3}}

For details, see
* http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/package-summary.html#package.description
* http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html
Bug: Add writable TimeToPurgeDeletes to ScanOptions
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Apr/21 00:07

In HBase 1.x and before, it was possible to override all settings on the ScanInfo when overriding the flush and compaction scanner open coprocoessors. HBase 2.x changed the coprocessor model to instead allow changes to a limited set of options on the ScanOptions object.  

In HBASE-19895 and HBASE-24321, we added support for KeepDeletedCells and MinVersions to be overriden by ScanOptions, as needed by Phoenix. 

A 1.x coprocessor used at my day job overrides TimeToPurgeDeletes, and to convert it to HBase 2.x that property would need to be overridable from ScanOptions as well. This should be a straightforward extension of the previous work.
Bug: [Flake Test][branch-1] TestSnapshotCloneIndependence's teardown() is always timeout
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Apr/21 04:17

The tearDown method after each test is always timeout.

So the fix is to
1. make the tearDown method without After annotation and make it private
2. move it under each test
3. Increase timeout to 30000 for each test, as for it is MediumTests.
Bug: Upgrade RpcControllerFactory and HBaseRpcController from Private to LimitedPrivate(COPROC,PHOENIX)
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Apr/21 20:39
Affects Version/s: 2.4.3

Phoenix has had an unrecognized dependency on RpcControllerFactory and HBaseRpcController for about four years. These interfaces are used to override setPriority for appropriate dispatch of requests for Phoenix system or index tables to separate pools. This is a reasonable use of these interfaces but the audience annotations were never updated to reflect this usage. Also seems reasonable to do so as there has been no issue here for four years. (Phoenix commit was made in 2017.) Make it official.
Bug: Retry REQUESTTIMEOUT KeeperExceptions from ZK
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 07/Apr/21 17:55
Affects Version/s: 2.3.6

Starting ZOOKEEPER-2251, client requests exceeding a timeout can throw a KeeperException with REQUESTTIMEOUT opcode set. RecoverableZookeeper doesn't transparently retry in such case. This was causing RS aborts when there is a flaky ZK quorum member serving slow requests (especially in cases like rolling upgrades and such).
Bug: hbase failed to write to multiple index table issue
Status: Resolved | Priority: Major | Resolution: Invalid
Created: 09/Apr/21 02:37
Affects Version/s: 1.2.6

 
  When we load data into phoenix(psql.py load csv file) table A, and at the same time we drop and create table B,in hbase log, we can 
  find one ERROR,that says index issue:
 ERROR 1121(XCL21): Write to the index failed.    disableIndexOnFailure=true,Failed to write multiple index tables
Any ideas for this issue?
Bug: Backport HBASE-25629 to branch-1
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Apr/21 22:39
Affects Version/s: 1.7.0

HBASE-25629 recently fixed an issue where TestCurrentHourProvider consistently failed on certain OSes due to quirks in time zone implementations. This test is also failing in branch-1, so in order to expedite a potential 1.7.0 release we should backport to branch-1 as well.
Bug: TestConnectionImplementation BadHostname tests fail in branch-1
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Apr/21 22:25
Affects Version/s: 1.7.0

TestConnectionImplementation.testGetAdminBadHostname and testGetClientBadHostname are consistently failing in branch-1. 

This is because they're assuming that the validity of the host is checked immediately upon getting the protobuf service object, when instead the service code purposefully waits until the first service call to check. 

I'll revise the tests to make service calls and verify that they return the correct exceptions (ServiceException wrapping an UnknownHostException).
Bug: MoveCostFunction is not included in the list of cost functions for StochasticLoadBalancer
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Apr/21 17:54
Affects Version/s: 1.7.0

After OffPeakHours fix for MoveCostFunction (HBASE-24709), MoveCostFunction is no longer included in costFunctions list. {{addCostFunction}} expects multiplier to be non-zero, but multiplier is now only set in {{cost}} function.

As a result, {{hbase.master.balancer.stochastic.maxMovePercent}} is not respected, and there is no cost function to oppose a move. Any move that decreases total cost at all will be accepted, causing more churn and disruption from balancer executions.

We noticed this when investigating a case where the balancer would run after a regionserver was restarted without use of region_mover script. The regionserver comes online with 0 regions, leading to a shortcut in {{needsBalance}} for {{idleRegionServerExist}}. The balancer runs to move regions to that newly restarted regionserver. However, it moves a large number of regions in the cluster, hyper-optimizing the other cost variables. There were ~4300 regions in the cluster at the time, so moving 25% of the regions should have had a final cost of at least 7 (default moveCostFunction weight.) MoveCostFunction is also not listed in the functions contributing to the initial cost.

{{2021-03-30 15:47:43,396 INFO [49187_ChoreService_3] balancer.StochasticLoadBalancer - start StochasticLoadBalancer.balancer, initCost=12.91377229840024, functionCost=RegionCountSkewCostFunction : (500.0, 0.014878672009326464); TableSkewCostFunction : (35.0, 0.013600280177445717); RegionReplicaHostCostFunction : (100000.0, 0.0); RegionReplicaRackCostFunction : (10000.0, 0.0); ReadRequestCostFunction : (5.0, 0.8296332203204705); WriteRequestCostFunction : (5.0, 0.06818455421617946); MemstoreSizeCostFunction : (5.0, 0.08132131691669181); StoreFileCostFunction : (5.0, 0.02054620605193966); computedMaxSteps: 1000000}}

{{2021-03-30 15:48:13,385 DEBUG [49187_ChoreService_3] balancer.StochasticLoadBalancer - Finished computing new load balance plan. Computation took 30004ms to try 6571 different iterations. Found a solution that moves 1095 regions; Going from a computed cost of 12.91377229840024 to a new cost of 4.804625730746651}}
Bug: remove files from filesCompacting when clear compaction queues
Status: Open | Priority: Minor | Resolution: 
Created: 11/May/21 16:54

When clear compaction queues, we just clear the workQueue of ThreadPoolExecutor, but files in compaction request are still in filesCompacting list. maybe we should clear it also.

For system compaction, selectNow will be false, which means files will be added to the compacting list when the compaction task is actually executed. So it is safe to just clear the workQueue of compaction thread pool executor.

However, for user-triggered compaction, selectNow will be true, which means files are already added to the compacting list when we put the compaction request to the queue. When CompactionPolicy selects candidate files for minor compaction, files in compacting list will be excluded. If we just clear the workQueue of compaction thread pool executor, files of these compaction requests are still in compacting list. These files will not be selected by CompactionPolicy and compacted any more unless we force a major compaction. So I think maybe we should remove those files from compacting list when we clear the compaction queue.
Bug: Disabled sanity checks ignored on snapshot restore
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 26/May/21 08:55
Affects Version/s: 2.2.6

Disabling sanity checks on a table is ignored when restoring snapshots. If this is expected behavior at least the error message is misleading.
h3. Steps *to Reproduce*
 # Create a new table
{{create 't', 'cf'}}
 # Add a coprocessor to the newly created table
{{alter 't', METHOD => 'table_att', 'coprocessor' => 'coprocessor.jar|com.example.MyCoprocessor|0'}}
 # Create a snapshot
{{snapshot 't', 'snapshot-t'}}
 # Disable the table to prevent region servers from crashing in the next step
{{disable 't'}}
 # Delete the coprocessor JAR and restart HBase.
 # Attempt to restore the snapshot leads to failing sanity check as expected
{{restore_snapshot 'snapshot-t'}}
{{ERROR: org.apache.hadoop.hbase.DoNotRetryIOException: coprocessor.jar Set hbase.table.sanity.checks to false at conf or table descriptor if you want to bypass sanity checks [...]}}
 # Disable sanity checks (as described in the error message) and retry
{{alter 't', CONFIGURATION => \{'hbase.table.sanity.checks' => 'false'}}}
{{restore_snapshot 'snapshot-t'}}

h3. Expected Behavior

The snapshot is restored.
h3. Actual Behavior

The same error message as in step 6. is shown.
Bug: StripeCompactionPolicy should support compacting cold regions
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Apr/21 13:18
Affects Version/s: 1.4.13

Cold regions cannot perform compactions by flushing memstores, while CompactionChecker can period check need compaction regions.

But some cold regions using stripe store engine may not be checked to perform compaction by`needCompaction()` or trigger automatic major compactions, because StripeCompactionPolicy#shouldPerformMajorCompaction() always returns false. 

StripeCompactionPolicy never performs automatic major compactions now.

But cold regions' outdated data need to be cleaned.
Bug: Improved logging when interrupting active RPC handlers holding the region close lock (HBASE-25212 hbase.regionserver.close.wait.abort)
Status: Open | Priority: Minor | Resolution: 
Created: 08/Apr/21 19:04
Affects Version/s: 1.7.0

HBASE-25212 adds an optional improvement to Close Region, for interrupting active RPC handlers holding the region close lock. If, after the timeout is reached, the close lock can still not be acquired, the regionserver may abort. It would be helpful to add logging for which threads or components are holding the region close lock at this time.

Depending on the size of regionLockHolders, or use of any stack traces, log output may need to be truncated. The interrupt code is in HRegion#interruptRegionOperations.
Bug: Fix various formatting issues in the refrence guide book
Status: In Progress | Priority: Minor | Resolution: 
Created: 11/May/21 14:51
Affects Version/s: 3.0.0-alpha-1

This jira is used to collect and fix various formatting issues in the refrence guide book.

For example,in the first paragraph of the chapter 8.1，the bulleted list is not displayed correctly，as show below：

!image-2021-05-11-22-55-13-810.png!
Bug: When turn on access control, the cell level TTL of Increment and Append operations is invalid.
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 14/Jun/21 11:32

AccessController postIncrementBeforeWAL() and postAppendBeforeWAL() methods will rewrite the new cell's tags by the old cell's. This will makes the other kinds of tag in new cell invisible (such as TTL tag) after this. As in Increment and Append operations, the new cell has already catch forward all tags of the old cell and TTL tag from mutation operation, here in AccessController we do not need to rewrite the tags once again. Also, the TTL tag of newCell will be invisible in the new created cell. Actually, in Increment and Append operations, the newCell has already copied all tags of the oldCell. So the oldCell is useless here.

{code:java}
private Cell createNewCellWithTags(Mutation mutation, Cell oldCell, Cell newCell) {
    // Collect any ACLs from the old cell
    List<Tag> tags = Lists.newArrayList();
    List<Tag> aclTags = Lists.newArrayList();
    ListMultimap<String,Permission> perms = ArrayListMultimap.create();
    if (oldCell != null) {
      Iterator<Tag> tagIterator = PrivateCellUtil.tagsIterator(oldCell);
      while (tagIterator.hasNext()) {
        Tag tag = tagIterator.next();
        if (tag.getType() != PermissionStorage.ACL_TAG_TYPE) {
          // Not an ACL tag, just carry it through
          if (LOG.isTraceEnabled()) {
            LOG.trace("Carrying forward tag from " + oldCell + ": type " + tag.getType()
                + " length " + tag.getValueLength());
          }
          tags.add(tag);
        } else {
          aclTags.add(tag);
        }
      }
    }

    // Do we have an ACL on the operation?
    byte[] aclBytes = mutation.getACL();
    if (aclBytes != null) {
      // Yes, use it
      tags.add(new ArrayBackedTag(PermissionStorage.ACL_TAG_TYPE, aclBytes));
    } else {
      // No, use what we carried forward
      if (perms != null) {
        // TODO: If we collected ACLs from more than one tag we may have a
        // List<Permission> of size > 1, this can be collapsed into a single
        // Permission
        if (LOG.isTraceEnabled()) {
          LOG.trace("Carrying forward ACLs from " + oldCell + ": " + perms);
        }
        tags.addAll(aclTags);
      }
    }

    // If we have no tags to add, just return
    if (tags.isEmpty()) {
      return newCell;
    }
    // Here the new cell's tags will be in visible.
    return PrivateCellUtil.createCell(newCell, tags);
  }
{code}
Bug: Make HRegion.getStores() an O(1) operation
Status: Open | Priority: Minor | Resolution: 
Created: 25/Jun/21 02:06

This is a relatively minor issue, but I did spot HRegion.getStores() popping up in my profiler.

Checking the code, I realized that HRegion.getStores() allocates a new array list in it, converting the Collection<> to List<>. But it also makes it an O( n ) in space and time complexity.

This conversion appears mostly unnecessary, because we only iterate the stores in production code, and so the new ArrayList object is thrown away immediately. Only in a number of test code where we index into the stores.

I suggest we should return the stores object directly, an O( 1 ) operation.
Bug: CompactionProgress WARNS: "totalCompactingKVs=N less than currentCompactedKVs=M"
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Apr/21 00:59
Affects Version/s: 2.4.3

Similar to HBASE-25642, but compaction progress warnings.

Lots of warnings like:

{noformat}
2021-04-30 00:55:15,436 WARN  [regionserver/ip-172-31-63-65:8120] 
compactions.CompactionProgress: totalCompactingKVs=15589 less than currentCompactedKVs=21411
{noformat}

{noformat}
2021-04-30 00:55:15,437 WARN  [regionserver/ip-172-31-63-65:8120] 
compactions.CompactionProgress: totalCompactingKVs=21916 less than currentCompactedKVs=33328
{noformat}

{noformat}
2021-04-30 00:55:15,438 WARN  [regionserver/ip-172-31-63-65:8120]
compactions.CompactionProgress: totalCompactingKVs=89731 less than currentCompactedKVs=92808
{noformat}

A couple of issues:

- Is there a way to make CompactionProgress more reliable? I seem to recall this is the second or third time around the block on this.

- This is annoying because compaction progress isn't always accurate, but this information is not used to determine anything significant, so WARN level is a bit much. (Or, if this is a real correctness problem, see point above.)
Bug: Update Reference Guide documentation for log4j2.xml
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 07/May/21 15:16
Affects Version/s: 3.0.0-alpha-1

In Apache HBase ™ Reference Guide

*Need to modify part：*

7.Default Configuration ->7.4. log4j.properties

*explanation：*

we need to update to 7.4 log4j2.xml
Bug: Relocate libnetty_transport_native_epoll_aarch_64.so in hbase-thirdparty
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Jun/21 00:18

Minor item I came across while trying to figure where all the netty native_epoll .so instances are coming from when I look at an hbase release.  We've relocated the x86 lib but not the aarch_64... Minor item.
Bug: hbase performance evaluation tool  could not support datasize more than 2048g
Status: Patch Available | Priority: Minor | Resolution: 
Created: 19/Jun/21 07:00
Affects Version/s: 2.1.0

in our daily test, we may hope to test more datasize than 2048g, when we set --size more than 2048g, pe print abnormal message like this:

[TestClient-1] hbase.PerformanceEvaluation: Start class org.apache.hadoop.hbase.PerformanceEvaluation$SequentialWriteTest at offset -1138166308 for -21474836 rows

 

this is due to variable totalRows in TestOptions defined by int(-2147483648  --- 2147483647), One GB is 1048576(1024*1024) by default. The max value of totalRow is  2147483647, in this condition, we may write not larger than 2147483647/1048576 = 2047.999G.
Bug: Move delete of WAL directory out of LOG.info and avoid left over directory
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Jun/21 18:18
Affects Version/s: 1.1.0

Followup the comment by [~anoopsamjohn] on HBASE-25921  (in [PR#88|https://github.com/apache/hbase-operator-tools/pull/88])

{quote} Not on this patch. But here is an issue. The actual delete() call happening within a Log statement. If INFO level not enabled, the delete wont get called. Can we fix that also here pls? {quote}