av9ash/GitBugs huggingface dataset:
Bug: Followup jira to encap all meta replica mode/selector processing into CatalogReplicaModeManager
Status: Open | Priority: Minor | Resolution: 
Created: 04/Nov/20 18:20

This is follow up with Stack's comments in [https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0.]

{quote}
h4. *[saintstack|https://github.com/saintstack]* [6 days ago|https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0#r514558880] 
Member
Yeah, said this before but in follow-on, would be good to shove all this stuff into a CatalogReplicaMode class. Internally this class would figure which policy to run. It would have a method that took a Scan that allowed decorating the Scan w/ whatever the mode needed to implement its policy. Later.
 
[!https://avatars1.githubusercontent.com/u/62515050?s=60&v=4|width=28,height=28!|https://github.com/huaxiangsun] 
h4. *[huaxiangsun|https://github.com/huaxiangsun]* [6 days ago|https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0#r514587250] 
Author Member
Now I thought about it, it makes sense. Maybe a CatalogReplicaModeManager class which encaps mode and selector?
Let me create a followup jira after this is merged.
 
{quote}
Bug: Followup jira to create single thread ScheduledExecutorService in AsyncConnImpl, and schedule all these periodic tasks
Status: Open | Priority: Minor | Resolution: 
Created: 04/Nov/20 18:41

This is a followup Jira for comments in [https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0.] 

{quote}
h4. *[saintstack|https://github.com/saintstack]* [18 hours ago|https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0#r517040579] Member
So, implements Stoppable rather than do what the likes of AuthUtil does where it does createDummyStoppable and then has an internal do-nothing Stoppable? Makes sense.

Perhaps add comment that it is a do-nothing stop required by ScheduledChore impls. s/isStopped/stopped/
 [!https://avatars1.githubusercontent.com/u/62515050?s=60&v=4|width=28,height=28!|https://github.com/huaxiangsun]
h4. *[huaxiangsun|https://github.com/huaxiangsun]* [18 hours ago|https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0#r517042290] Author Member
Will do.
 [!https://avatars2.githubusercontent.com/u/45484?s=60&v=4|width=28,height=28!|https://github.com/ndimiduk]
h4. *[ndimiduk|https://github.com/ndimiduk]* [17 hours ago|https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0#r517057141] Member
Maybe in the future we can put a default empty implementation on the interface, and then implementers who don't need it can ignore it.
 [!https://avatars3.githubusercontent.com/u/4958168?s=60&u=fc28b222c03c02201d705b025a5293d6c471f7b3&v=4|width=28,height=28!|https://github.com/Apache9]
h4. *[Apache9|https://github.com/Apache9]* [17 hours ago|https://github.com/apache/hbase/pull/2584/commits/d99c2b0ccfd2a57150e984742d097d1e1fcc47b0#r517057999] Member
Maybe we could just use a ScheduledExecutorService at client side, the ChoreService is designed to be used at server side I believe. Anyway, not a blocker for now.

{quote}
Bug: gson format of RpcServer.logResponse is abnormal
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 03/Nov/20 07:53
Affects Version/s: 2.2.6

It will turn ‘=’ into ‘\u003d’.

ipc.RpcServer(550): (responseTooSlow): {"call":"Multi(org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$MultiRequest)","multi.gets":0,"starttimems":"1604389131993","responsesize":"64","method":"Multi","param":"region{color:#ff0000}\u003d{color} test,,1604389129684.8812226d0f8942b24892c79e3c393b26., for 10 action(s) and 1st row key{color:#ff0000}\u003d{color}11","processingtimems":20,"client":"172.1.0.3:61264","queuetimems":0,"multi.servicecalls":0,"class":"MiniHBaseClusterRegionServer","multi.mutations":10}
Bug: [branch-1] Fix Java 11 runtime issue in UnsafeAccess
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Oct/20 22:18

When running tests with Java 11 UnsafeAccess is observed to throw NoSuchMethodErrors. Some of our methods accept 'int' parameters and use them as parameters to Unsafe methods which should take 'long'. Not an issue on branch-2 and up.
Bug: Add support for row prefix and type in the WAL Pretty Printer and some minor fixes
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 18/Oct/20 04:57

Currently, the WAL Pretty Printer has an option to filter the keys with an exact match of row. However, it is super useful sometimes to have a row key prefix instead of an exact match.

The prefix can act as a full match filter as well due to the nature of the prefix.

Secondly, we are not having the cell type in the WAL Pretty Printer in any of the branches. 
Lastly, the option rowkey only options prints additional stuff as well.
Bug: [branch-1] getNumOpenConnections is not effective
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 18/Oct/20 07:00

In MetricsHBaseServerWrapperImpl
{code}
  @Override
  public int getNumOpenConnections() {
    if (!isServerStarted() || this.server.connectionList == null) {
      return 0;
    }
    return server.connectionList.size();
  }
{code}
But connectionList is created by Collections.synchronizedList(new LinkedList<Connection>());
So each connectionList.size() will compete for the mutex, we can easily replace it with another parameter *numConnections*, as for metrics, it is enough.
Bug: While emitting the memstore read based metrics use # instead of _ while emitting them metric
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 01/Oct/20 04:46

We do have table names with '_' in it. so it should be '#' that we use as the seperator when we emit the metric out. 
Usually _ is used for all other metric detail but here since we do that grouping of the metric based on table and store name - it is better we use another seperator instead of '_' for these metrics.
Bug: Add CLI support to remove a particular configuration from ReplicationPeerConfig.
Status: Resolved | Priority: Minor | Resolution: Not A Problem
Created: 20/Oct/20 18:39

Currently, there is no easy way to remove a configuration from ReplicationPeerConfig after it is being set.

This can come in handy at multiple instances when we want to remove a particular configuration when it's not needed anymore or it is causing unexpected behavior. For eg in case there is a need to remove a walFilter (hbase.replication.source.custom.walentryfilters) configuration.

As part of this Jira we want to add that support.
Bug: Running an hbase-shell command in non-interactive mode should not complain about missing files when it fails to talk to the cluster.
Status: Open | Priority: Minor | Resolution: 
Created: 20/Oct/20 16:27

if you script out some shell commands, then run them via the shell in non-interactive mode we sometimes give an erroneous "I couldn't find that file" response when the master(s) are in a bad state instead of revealing the underlying cluster issue.

e.g.
{code}
  tmpfile=$(mktemp)
  echo "balance_switch false" > $tmpfile
  echo "exit" >> $tmpfile
  $HBASE_BIN --config $CONF_DIR shell -n $tmpfile
  RET=$?
  rm $tmpfile
  exit $RET
{code}

as an example, with a master stuck trying to initialize as active the failure might look like

{code}
++ mktemp
+ tmpfile=/tmp/tmp.dMHTj0nVXx
+ echo balance_switch true
+ echo exit
+ bin/hbase --config /etc/hbase/conf shell -n /tmp/tmp.dMHTj0nVXx
LoadError: no such file to load -- /tmp/tmp.dMHTj0nVXx
    load at org/jruby/RubyKernel.java:974
  <main> at /some/path/to/lib/hbase/bin/hirb.rb:186
+ RET=1
+ rm /tmp/tmp.dMHTj0nVXx
+ exit 1
{code}

which is very confusing. the shell should report something related to an issue talking to the cluster rather than a problem with the passed script.
Bug: Assert format is incorrect in HFilePerformanceEvaluation class.
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 12/Oct/20 16:12

[HFilePerformanceEvaluation |https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/HFilePerformanceEvaluation.java#L518] 
The format of expected and actual is interchanged.

{code:java}
PerformanceEvaluationCommons.assertValueSize(c.getValueLength(), ROW_LENGTH);
{code}
The first argument should be expected and second should be actual.
Bug: Remove branch-1.3 from precommit and docs
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 01/Oct/20 20:32
Affects Version/s: 3.0.0-alpha-1

Following the [announcement|https://lists.apache.org/thread.html/r9552e9085aaac2a43f8b26b866d34825a84a9be7f19118ac560d14de%40%3Cuser.hbase.apache.org%3E] to EOL branch-1.3, update the precommit script to not consider this branch any longer, and refresh mentions of this branch in the doc.
Bug: [Documentation] fix duplicate conf entry
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 17/Nov/20 03:48

[hbase.rolling.restart|https://hbase.apache.org/book.html#hbase.rolling.restart]
{panel:title=HBase 2.0+ can no longer read Sequence File based WAL file.}
HBase can no longer read the deprecated WAL files written in the Apache Hadoop Sequence File format. The hbase.regionserver.hlog.reader.impl and hbase.regionserver.hlog.reader.impl configuration entries should be set to use the Protobuf based WAL reader / writer classes. This implementation has been the default since HBase 0.96, so legacy WAL files should not be a concern for most downstream users.
{panel}
It should be:

"The _hbase.regionserver.hlog.reader.impl_ and _hbase.regionserver.hlog.writer.impl_ "...
Bug: [Documentation] Fix spelling error in sync_replication.adoc
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 07/Dec/20 06:41
Affects Version/s: 3.0.0-alpha-1

h2. 99. Operation and maintenance
{quote}Case.3 How to operate when active cluster crashed

If the active cluster has been crashed (it may be not reachable now), so let’s just transit the standby cluster to DOWNGRANDE_ACTIVE state, and after that, we should redirect all the requests from client to the DOWNGRADE_ACTIVE cluster.
{quote}
It should be:
"so let’s just transit the standby cluster to *DOWNGRADE_ACTIVE* state."
Bug: [Documentation]  Fix spelling error
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 03/Dec/20 11:40

[164.8.1. Understanding the output|https://hbase.apache.org/book.html#_understanding_the_output]
{quote}This could also happen if replication is manually paused (via hbase shell disable_peer command, for example), but date keeps getting ingested in the source cluster tables.{quote}
It should be:
"but *_data_* keeps getting ingested in the source cluster tables."
Bug: Document deprecation of HConstants#REPLICATION_DROP_ON_DELETED_TABLE_KEY
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 18/Oct/20 19:20
Affects Version/s: 3.0.0-alpha-1

HBASE-24359 deprecated HConstants#REPLICATION_DROP_ON_DELETED_TABLE_KEY. It should also be noted down in Javadoc when it was deprecated and when it is expected to be removed.
Bug: Snapshot working dir does not retain ACLs after snapshot commit phase
Status: Resolved | Priority: Blocker | Resolution: Fixed
Created: 13/Sep/23 10:26

TestSnapshotScannerHDFSAclController is failing 100% on flaky dashboard.

 

After snapshot is committed from working dir to final destination (under /.hbase-snapshot dir), if the operation was atomic rename, the working dir (e.g. /hbase/.hbase-snapshot/.tmp) no longer preserves ACLs that were derived from snapshot parent dir (e.g. /hbase/.hbase-snapshot) while creating first working snapshot dir. Hence, for new working dir, we should ensure that we preserve ACLs from snapshot parent dir.

This would ensure that final snapshot commit dir has the expected ACLs regardless of whether we perform atomic rename of non-atomic copy operation in the snapshot commit phase.
Bug: Replication stuck after switching to new WAL but the queue is empty
Status: Resolved | Priority: Blocker | Resolution: Fixed
Created: 22/Aug/23 01:13
Affects Version/s: 2.5.5

When the speed of consuming replication WALs is high, and there are something wrong when creating new WAL, the swith of replcation source reader to new WAL in the queue may happen before the new WAL is created, then the replcation will stuck since it can not consume the new WALs soon afterwards anymore. Restarting the RS that replication stucking can make the replication recover.
Bug: Connection attributes can become corrupted on the server side
Status: Resolved | Priority: Blocker | Resolution: Fixed
Created: 05/Aug/23 01:13

In ServerRpcConnection.processOneRpc, it calls processConnectionHeader and then immediately calls callCleanupIfNeeded. The parsing of the ByteBuff into the ConnectionHeader does not copy the bytes. We keep a reference to ConnectionHeader for later use, but since the underlying ByteBuff gets released in callCleanupIfNeeded, later requests can override the memory locations that the ConnectionHeader points at.

The unit tests we added dont catch this possibly because they don't send enough requests to corrupt the buffers. It happens pretty quickly in a deployed cluster.

We need to copy the List<NameBytesPair> from the ConnectionHeader into a Map before the buffer is released. This probably means we should remove getConnectionHeader from the RpcCall interface and instead add getConnectionAttributes.
Bug: Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
Status: Resolved | Priority: Critical | Resolution: Duplicate
Created: 01/Sep/23 07:01
Affects Version/s: 2.4.14

In our production environment, Region server JVM is getting crashed randomly with the following error logs.
{code:java}
Stack: [0x0000fffdd32d8000,0x0000fffdd34d8000],  sp=0x0000fffdd34d6000,  free space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v  ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2 org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V (53 bytes) @ 0x0000ffff8cc9a154 [0x0000ffff8cc9a040+0x114]
C  [ld-linux-aarch64.so.1+0x40018]  _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
 

We are using HBase 2.4.14.
Bug: AbstractFSWAL causes ArithmeticException due to improper logRollSize value checking
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 27/Jul/23 14:50

h2. What happened

There is no value checking for parameter {{hbase.regionserver.logroll.multiplier}} when {{hbase.wal.provider}} is set to {{multiwal}}. This may cause improper calculations and crashes the system like division by 0.
h2. Buggy code

In {{AbstractFSWAL.java}}, there is no value checking for {{logRollSize and this variable is directly used while calculating the value of maxLogFiles in the method calculateMaxLogFiles}}. When logRollSize is mistakenly set to 0, the code would cause division by 0 and throw {{ArithmeticException}} to crash the system.
{noformat}
     private int calculateMaxLogFiles(Configuration conf, long logRollSize) {
    Pair<Long, MemoryType> globalMemstoreSize = MemorySizeUtil.getGlobalMemStoreSize(conf);
    return (int) ((globalMemstoreSize.getFirst() * 2) / logRollSize);
  }{noformat}
h2. How to reproduce

(1) set hbase.regionserver.logroll.multiplier=0.0 and hbase.wal.provider=multiwal
(2) run org.apache.hadoop.hbase.wal.TestWALMethods#testGetSplitEditFilesSorted
you should observe the following failure:
{noformat}
java.lang.ArithmeticException: / by zero
	at org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.calculateMaxLogFiles(AbstractFSWAL.java:466)	at org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.<init>(AbstractFSWAL.java:594)	at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.<init>(AsyncFSWAL.java:141)        . . .{noformat}
For an easy reproduction, run the reproduce.sh in the attachment.

We are happy to provide a patch if this issue is confirmed.
Bug: BucketCache causes ArithmeticException due to improper blockSize value checking 
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 24/Jul/23 16:43

h2. What happened

There is no value checking for parameter {{{}hbase.blockcache.minblocksize{}}}. This may cause improper calculations and crashes the system like division by 0.
h2. Buggy code

In {{{}BucketCache.java{}}}, there is no value checking for {{blockSize}} and this variable is directly used to calculate the {{{}blockNumCapacity{}}}. When {{blockSize}} is mistakenly set to 0, the code would cause division by 0 and throw ArithmeticException to crash the system.
{noformat}
  public BucketCache(String ioEngineName, long capacity, int blockSize, int[] bucketSizes,
    int writerThreadNum, int writerQLen, String persistencePath, int ioErrorsTolerationDuration,
    Configuration conf) throws IOException {
    ...
    long blockNumCapacity = capacity / blockSize;
    ...{noformat}
h2. How to reproduce

(1) set hbase.blockcache.minblocksize=0
(2) run org.apache.hadoop.hbase.io.hfile.TestCacheConfig#testBucketCacheConfigL1L2Setup

you should observe the following failure:
{noformat}
java.lang.ArithmeticException: / by zero
    at org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.<init>(BucketCache.java:282)
    at org.apache.hadoop.hbase.io.hfile.BlockCacheFactory.createBucketCache(BlockCacheFactory.java:238)
    at org.apache.hadoop.hbase.io.hfile.BlockCacheFactory.createBlockCache(BlockCacheFactory.java:110)
    at org.apache.hadoop.hbase.io.hfile.TestCacheConfig.testBucketCacheConfigL1L2Setup(TestCacheConfig.java:325)
        ...{noformat}
For an easy reproduction, run the reproduce.sh in the attachment.

We are happy to provide a patch if this issue is confirmed.
Bug: ByteBuffAllocator causes ArithmeticException due to improper poolBufSize value checking
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 24/Jul/23 16:41

h3. What happened

There is no value checking for parameter {{{}hbase.server.allocator.buffer.size{}}}. This may cause improper calculations and crashes the system like division by 0.
h3. Buggy code

In {{{}ByteBuffAllocator.java{}}}, there is no value checking for {{poolBufSize}} and this variable is directly used to calculate the {{{}bufsForTwoMB{}}}. When {{poolBufSize}} is mistakenly set to 0, the code would cause division by 0 and throw ArithmeticException to crash the system.
{noformat}
public static ByteBuffAllocator create(Configuration conf, boolean reservoirEnabled) {
    int poolBufSize = conf.getInt(BUFFER_SIZE_KEY, DEFAULT_BUFFER_SIZE);
    if (reservoirEnabled) {
    . . .
    int bufsForTwoMB = (2 * 1024 * 1024) / poolBufSize;
    . . .{noformat}
h3. How to reproduce
 # set hbase.server.allocator.buffer.size=0
run
 #  org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCacheRefCnt#testInBucketCache
 # you should observe the following failure:

{noformat}
java.lang.ArithmeticException: / by zero
    at org.apache.hadoop.hbase.io.ByteBuffAllocator.create(ByteBuffAllocator.java:174)
    at org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCacheRefCnt.testInBucketCache(TestBucketCacheRefCnt.java:224)
    . . .{noformat}
For an easy reproduction, run the reproduce.sh in the attachment. We are happy to provide a patch if this issue is confirmed.
Bug: Adding debug message and assertion for failed BlockCache creation
Status: Open | Priority: Critical | Resolution: 
Created: 20/Jul/23 08:07

h2. What happened

After setting {{{}hfile.block.cache.size=1.1175870895385742E-8{}}}, running test {{org.apache.hadoop.hbase.io.hfile.TestBlockCacheReporting#testLruBlockCache}} results in a {{{}NullPointerException{}}}.
h2. Where's the bug

In the test {{{}org.apache.hadoop.hbase.io.hfile.TestBlockCacheReporting#testLruBlockCache{}}}:
{code:java}
    BlockCache blockCache = BlockCacheFactory.createBlockCache(this.conf);
    logPerBlock(blockCache);
    addDataAndHits(blockCache, 3); {code}
Here the returned blockCache could be null, but is directly used as the parameter of {{logPerBlock}} without checking.
h2. How to reproduce
 # Set {{hfile.block.cache.size=1.1175870895385742E-8}}
 # Run {{org.apache.hadoop.hbase.io.hfile.TestBlockCacheReporting#testLruBlockCache}}
and the following exception should be observed:

{code:java}
java.lang.NullPointerException	at org.apache.hadoop.hbase.io.hfile.TestBlockCacheReporting.logPerBlock(TestBlockCacheReporting.java:147)	at org.apache.hadoop.hbase.io.hfile.TestBlockCacheReporting.testLruBlockCache(TestBlockCacheReporting.java:100) {code}

{{}}
Bug:  Missing null check in TestHFile
Status: Open | Priority: Critical | Resolution: 
Created: 27/Jul/23 15:22

h2. What happened

After setting {{{}hbase.lru.blockcache.hard.capacity.limit.factor=-0.4921875{}}}, running test {{{}org.apache.hadoop.hbase.io.hfile.TestHFile#testReaderWithAdaptiveLruCombinedBlockCache{}}}results in a null pointer exception.
h2. Where's the problem

In the test:
{noformat}
      cachedBlock = combined.getBlock(key, false, false, true);
      try {
...
      } finally {
        cachedBlock.release();
      }{noformat}
However, cacheBlock might not be initialized properly and could be null, causing an unhandled NullPointerException.
h2. How to reproduce
 # set {{hbase.lru.blockcache.hard.capacity.limit.factor}} to {{-0.4921875 }}
 # run {{org.apache.hadoop.hbase.io.hfile.TestHFile#testReaderWithAdaptiveLruCombinedBlockCache}}
you should observe
{noformat}
java.lang.NullPointerException
    at org.apache.hadoop.hbase.io.hfile.TestHFile.testReaderCombinedCache(TestHFile.java:1052)
    at org.apache.hadoop.hbase.io.hfile.TestHFile.testReaderWithAdaptiveLruCombinedBlockCache(TestHFile.java:1011){noformat}
For an easy reproduction, run the reproduce.sh in the attachment.

We are happy to provide a patch if this issue is confirmed.
Bug: Should check the return value of protobuf Message.mergeDelimitedFrom
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 20/Sep/23 07:04

Found this problem while upgrading thirdparty dependencies.

The javadoc of mergeDelimitedFrom says

{code}
    /**
     * Like {@link #mergeFrom(InputStream)}, but does not read until EOF. Instead, the size of the
     * message (encoded as a varint) is read first, then the message data. Use {@link
     * MessageLite#writeDelimitedTo(OutputStream)} to write messages in this format.
     *
     * @return true if successful, or false if the stream is at EOF when the method starts. Any
     *     other error (including reaching EOF during parsing) causes an exception to be thrown.
     * @throws InvalidProtocolBufferException the bytes read are not syntactically correct
     *     according to the protobuf wire format specification. The data is corrupt, incomplete,
     *     or was never a protobuf in the first place.
     * @throws IOException an I/O error reading from the stream
     */
{code}

So we should not ignore the return value, otherwise we may get an incomplete message.
Bug: org.apache.hadoop.hbase.TestHBaseTestingUtility failed when setting call queue read ratio to a large value
Status: Open | Priority: Critical | Resolution: 
Created: 20/Jul/23 08:00

h2. What happened

{{org.apache.hadoop.hbase.TestHBaseTestingUtility#testMiniZooKeeperWithMultipleServers}} failed when trying to run with {{hbase.ipc.server.callqueue.read.ratio=1782718229}}
h2. How to reproduce
 # set {{hbase.ipc.server.callqueue.read.ratio=1782718229}}
 # run {{org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler#testCallQueueInfo}}
you should observe the following failure:


{code:java}
java.lang.AssertionError: expected:<10> but was:<9>	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.ipc.TestSimpleRpcScheduler.testCallQueueInfo(TestSimpleRpcScheduler.java:176) {code}