[jira] [Created] (HBASE-25934) Add username for RegionScannerHolder

[tomscut (Jira)]

tomscut created HBASE-25934:
---

 Summary: Add username for RegionScannerHolder
 Key: HBASE-25934
 URL: https://issues.apache.org/jira/browse/HBASE-25934
 Project: HBase
  Issue Type: Wish
Reporter: tomscut


This JIRA[HBASE-25542|https://issues.apache.org/jira/browse/HBASE-25542] has 
added part of the client information before, we can also add username for 
RegionScannerHolder.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-25908) Exclude jakarta.activation-api

[Michael Stack (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Stack resolved HBASE-25908.
---
Fix Version/s: 2.5.0
   3.0.0-alpha-1
 Hadoop Flags: Reviewed
 Tags: hadoop-3.3.1
   Resolution: Fixed

Merged to master and branch-2. Should I backport to branch-2.4 [~apurtell] ? 
You want to run on hadoop 3.3.1? Otherwise, hbase-2.5 to run on hadoop-3.3.1?

Thanks for the fix and the nice background [~weichiu].

> Exclude jakarta.activation-api
> --
>
> Key: HBASE-25908
> URL: https://issues.apache.org/jira/browse/HBASE-25908
> Project: HBase
>  Issue Type: Improvement
>  Components: hadoop3, shading
>Affects Versions: 2.3.0
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0
>
>
> Hadoop 3.3.1 replaced its dependency of javax.activation 1.2.0 with 
> jakarta.activation 1.2.1.
> They are essentially the same thing (they even have the same classpath name), 
> but Eclipse took over JavaEE development and therefore changed group/artifact 
> id. 
> (https://stackoverflow.com/questions/46493613/what-is-the-replacement-for-javax-activation-package-in-java-9)
> See HADOOP-17049 for more details. Hadoop 3.3.0 updated jackson-databind to 
> 2.10 which shades jakarta.activation, causing classpath conflict.
> The solution to this issue will be similar to HBASE-22268



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-25758) Move MetaTableAccessor out of hbase-balancer module

[Duo Zhang (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-25758.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Merged to master.

Thanks [~niuyulin] for reviewing.

> Move MetaTableAccessor out of hbase-balancer module
> ---
>
> Key: HBASE-25758
> URL: https://issues.apache.org/jira/browse/HBASE-25758
> Project: HBase
>  Issue Type: Sub-task
>  Components: Balancer, meta
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0-alpha-1
>
>
> It should not be there.
> The only reason we have to put it there is the favor node balancer. The favor 
> node balancer does not work well so maybe we could just purge it.
>  update 
> With HBASE-25926 in place we could just move it directly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: master branch issues when running with jdk8

[Duo Zhang]

I prefer we still support JDK8 for 3.0.0, and then add JDK17 support and
drop JDK8 for 4.0.0.

We could do this in the second half of this year after we cut branch-3.

Stack  于2021年5月28日周五 上午8:38写道：

> On Thu, May 27, 2021 at 7:34 AM Wellington Chevreuil <
> wellington.chevre...@gmail.com> wrote:
>
> > ... I guess this was
> > not expected, and our official goal is to still support jdk8 for the
> > upcoming 3.0 release?
> >
>
> I'd suggest dropping jdk8 support in hbase3.
> S
>

Re: master branch issues when running with jdk8

[Stack]

On Thu, May 27, 2021 at 7:34 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:

> ... I guess this was
> not expected, and our official goal is to still support jdk8 for the
> upcoming 3.0 release?
>

I'd suggest dropping jdk8 support in hbase3.
S

Re: [VOTE] Second release candidate for HBase 2.4.3 (RC1) is available

[Stack]

+1

   * Signature: ok
* Checksum : ok
* Rat check (1.8.0_191): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_191): ok
 - mvn clean install -DskipTests
* Unit tests pass (1.8.0_191): failed
 - mvn package -P runSmallTests

The test failed because I had my vpn up which clashes w/ the kerberos test.

Changes and release notes look good (did not verify changes matches issues
in git).
API compat looks good.
Started up standalone with binary built from src. Loaded and verified data
made it. Exercised shell. Looked at UI.

S

On Thu, May 20, 2021 at 12:11 PM Andrew Purtell  wrote:

> Please vote on this Apache HBase release candidate, hbase-2.4.3RC1.
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache HBase 2.4.3
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.3RC1:
>
> https://github.com/apache/hbase/tree/2.4.3RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.3RC1/
>
> These sources correspond with the git tag "2.4.3RC1" (401b60b217).
>
> Temporary Maven artifacts are available in the staging repository:
>
>
> https://repository.apache.org/content/repositories/orgapachehbase-1447/
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.3RC1/api_compare_2.4.2_to_2.4.3RC1.html
>
> We performed the following successful pre-flight checks before
> announcing the previous RC, RC0:
>
> - Unit tests
>
> - 10 TB Common Crawl data load via IntegrationTestLoadCommonCrawl,
>   slowDeterministic policy
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>

[VOTE] The Release Candidate for HBase 1.7.0 (RC0) is available for download

[Reid Chan]

Hi team,

The first release candidate for HBase 1.7.0 is available for download:
https://dist.apache.org/repos/dist/dev/hbase/1.7.0RC0/

Maven artifacts are available in a staging repository at:
https://repository.apache.org/content/repositories/orgapachehbase-1449

A detailed source and binary compatibility report for this release is at:
https://dist.apache.org/repos/dist/dev/hbase/1.7.0RC0/compat-check-report.html

A list of the issues resolved in this release can be found at:
https://s.apache.org/jira/170


Flaky unit tests can be found at:
https://ci-hadoop.apache.org/job/HBase/job/HBase-Find-Flaky-Tests/job/branch-1/Flaky_20Test_20Report/

Notable changes:

   - hbase-thrift module is excluded by default due to JDK support issue.
   For those who need thrift service should build the source code using JDK8.
   - support zookeeper 3.6.0+
   - Relocate test-only REST "client" from src/ to test/ and mark Private
   (this is also showed in compat report)

Please try out this candidate and vote +1 or -1 with reasons.

The VOTE will remain open for at least 72 hours.

Thanks!

--
Best regards,
R.C

Re: HBase JIRA admin requests

[Sean Busbey]

added!

On Thu, May 27, 2021 at 2:13 PM Reid Chan  wrote:
>
> Hi team,
>
> I'm working on the hbase-1.7.0 release, but found I couldn't add a new tag
> for unreleased versions, could someone grant me the access?
>
> Thanks.
>
> ---
> Best Regards,
> R.C

HBase JIRA admin requests

[Reid Chan]

Hi team,

I'm working on the hbase-1.7.0 release, but found I couldn't add a new tag
for unreleased versions, could someone grant me the access?

Thanks.

---
Best Regards,
R.C

[jira] [Resolved] (HBASE-25933) Log trace raw exception, instead of cause message in NettyRpcServerRequestDecoder

[Wellington Chevreuil (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wellington Chevreuil resolved HBASE-25933.
--
Resolution: Fixed

Thanks for reviewing [~rushabh.shah] [~psomogyi] [~elserj]!

> Log trace raw exception, instead of cause message in 
> NettyRpcServerRequestDecoder
> -
>
> Key: HBASE-25933
> URL: https://issues.apache.org/jira/browse/HBASE-25933
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 3.0.0-alpha-1, 2.2.7, 2.5.0, 2.3.5, 2.4.3
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
>
> In *NettyRpcServerRequestDecoder,* override of *exceptionCaught* method tries 
> to log the exception cause message, however this not always will have a 
> content, causing debugging of connection failure issues harder to 
> troubleshoot. We should simply log trace the observed *Throwable* reference 
> itself:
>  
> {noformat}
> diff --git 
> a/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
>  
> b/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
> index 1e844bb02cb..40f59ad1259 100644
> --- 
> a/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
> +++ 
> b/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
> @@ -74,7 +74,7 @@ class NettyRpcServerRequestDecoder extends 
> ChannelInboundHandlerAdapter {
>    public void exceptionCaught(ChannelHandlerContext ctx, Throwable e) {
>      allChannels.remove(ctx.channel());
>      NettyRpcServer.LOG.trace("Connection {}; caught unexpected downstream 
> exception.",
> -        ctx.channel().remoteAddress(), e.getCause());
> +        ctx.channel().remoteAddress(), e);
>      ctx.channel().close();
>    }
>  }
>  {noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (HBASE-25924) Seeing a spike in uncleanlyClosedWALs metric.

[Andrew Kyle Purtell (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kyle Purtell reopened HBASE-25924:
-

This change causes a consistent test failure on master branch (at least). It's 
been showing up in recent precommit reports. 

{noformat}
[ERROR] Failures: 
[ERROR] 
org.apache.hadoop.hbase.replication.regionserver.TestWALEntryStream.testCleanClosedWALs
[ERROR]   Run 1: TestWALEntryStream.testCleanClosedWALs:882 expected:<0> but 
was:<1>
[ERROR]   Run 2: TestWALEntryStream.testCleanClosedWALs:882 expected:<0> but 
was:<1>
[ERROR]   Run 3: TestWALEntryStream.testCleanClosedWALs:882 expected:<0> but 
was:<1>
{noformat}

We need an addendum test fix, or a revert. 

> Seeing a spike in uncleanlyClosedWALs metric.
> -
>
> Key: HBASE-25924
> URL: https://issues.apache.org/jira/browse/HBASE-25924
> Project: HBase
>  Issue Type: Bug
>  Components: Replication, wal
>Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.5.0, 2.4.4
>Reporter: Rushabh Shah
>Assignee: Rushabh Shah
>Priority: Major
> Fix For: 3.0.0-alpha-1, 1.7.0, 2.5.0, 2.3.6, 2.4.4
>
>
> Getting the following log line in all of our production clusters when 
> WALEntryStream is dequeuing WAL file.
> {noformat}
>  2021-05-02 04:01:30,437 DEBUG [04901996] regionserver.WALEntryStream - 
> Reached the end of WAL file hdfs://. It was not closed 
> cleanly, so we did not parse 8 bytes of data. This is normally ok.
> {noformat}
> The 8 bytes are usually the trailer serialized size (SIZE_OF_INT (4bytes) + 
> "LAWP" (4 bytes) = 8 bytes)
> While dequeue'ing the WAL file from WALEntryStream, we reset the reader here.
> [WALEntryStream|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/WALEntryStream.java#L199-L221]
> {code:java}
>   private void tryAdvanceEntry() throws IOException {
> if (checkReader()) {
>   readNextEntryAndSetPosition();
>   if (currentEntry == null) { // no more entries in this log file - see 
> if log was rolled
> if (logQueue.getQueue(walGroupId).size() > 1) { // log was rolled
>   // Before dequeueing, we should always get one more attempt at 
> reading.
>   // This is in case more entries came in after we opened the reader,
>   // and a new log was enqueued while we were reading. See HBASE-6758
>   resetReader(); ---> HERE
>   readNextEntryAndSetPosition();
>   if (currentEntry == null) {
> if (checkAllBytesParsed()) { // now we're certain we're done with 
> this log file
>   dequeueCurrentLog();
>   if (openNextLog()) {
> readNextEntryAndSetPosition();
>   }
> }
>   }
> } // no other logs, we've simply hit the end of the current open log. 
> Do nothing
>   }
> }
> // do nothing if we don't have a WAL Reader (e.g. if there's no logs in 
> queue)
>   }
> {code}
> In resetReader, we call the following methods, WALEntryStream#resetReader  
> >  ProtobufLogReader#reset ---> ProtobufLogReader#initInternal.
> In ProtobufLogReader#initInternal, we try to create the whole reader object 
> from scratch to see if any new data has been written.
> We reset all the fields of ProtobufLogReader except for ReaderBase#fileLength.
> We calculate whether trailer is present or not depending on fileLength.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: master branch issues when running with jdk8

[Wellington Chevreuil]

Thanks Andrew!

On Thu, 27 May 2021, 17:25 Andrew Purtell,  wrote:

> There is a JIRA for using the new —release build flag available in JDK 9+
> to safely build binaries meant to run on JDK8. See
> https://issues.apache.org/jira/browse/HBASE-25465
>
> This issue with the ByteBuffer signature change and linkage problems is
> exactly what motivated me to look into it.
>
> > On May 27, 2021, at 7:34 AM, Wellington Chevreuil <
> wellington.chevre...@gmail.com> wrote:
> >
> > I had faced below errors when trying to run current master branch
> version
> > on jdk8 (build was also on jdk8):
> >
> > 2021-05-26T23:02:20,202 TRACE [RS-EventLoopGroup-1-1]
> > ipc.NettyRpcServer: Connection /192.168.56.105:44592; caught
> > unexpected downstream exception.
> >> java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
> >>at
> org.apache.hadoop.hbase.ipc.NettyRpcServerPreambleHandler.channelRead0(NettyRpcServerPreambleHandler.java:48)
> ~[hbase-server-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
> >>
> >>
> > This specific netty related one happens when RSes try to check into
> Master,
> > leaving the cluster unusable, but the same NSME happens at other parts of
> > the code too, eventually causing processes to crash.
> >
> > Running on jdk11 fixes it. Anyone else seeing the same? I guess this was
> > not expected, and our official goal is to still support jdk8 for the
> > upcoming 3.0 release?
>

Re: master branch issues when running with jdk8

[Andrew Purtell]

There is a JIRA for using the new —release build flag available in JDK 9+ to 
safely build binaries meant to run on JDK8. See 
https://issues.apache.org/jira/browse/HBASE-25465

This issue with the ByteBuffer signature change and linkage problems is exactly 
what motivated me to look into it. 

> On May 27, 2021, at 7:34 AM, Wellington Chevreuil 
>  wrote:
> 
> I had faced below errors when trying to run current master branch version
> on jdk8 (build was also on jdk8):
> 
> 2021-05-26T23:02:20,202 TRACE [RS-EventLoopGroup-1-1]
> ipc.NettyRpcServer: Connection /192.168.56.105:44592; caught
> unexpected downstream exception.
>> java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
>>at 
>> org.apache.hadoop.hbase.ipc.NettyRpcServerPreambleHandler.channelRead0(NettyRpcServerPreambleHandler.java:48)
>>  ~[hbase-server-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
>> 
>> 
> This specific netty related one happens when RSes try to check into Master,
> leaving the cluster unusable, but the same NSME happens at other parts of
> the code too, eventually causing processes to crash.
> 
> Running on jdk11 fixes it. Anyone else seeing the same? I guess this was
> not expected, and our official goal is to still support jdk8 for the
> upcoming 3.0 release?

[jira] [Created] (HBASE-25933) Log trace raw exception, instead of cause message in NettyRpcServerRequestDecoder

[Wellington Chevreuil (Jira)]

Wellington Chevreuil created HBASE-25933:


 Summary: Log trace raw exception, instead of cause message in 
NettyRpcServerRequestDecoder
 Key: HBASE-25933
 URL: https://issues.apache.org/jira/browse/HBASE-25933
 Project: HBase
  Issue Type: Improvement
Reporter: Wellington Chevreuil
Assignee: Wellington Chevreuil


In *NettyRpcServerRequestDecoder,* override of *exceptionCaught* method tries 
to log the exception cause message, however this not always will have a 
content, causing debugging of connection failure issues harder to 
troubleshooting. We should simply log trace the observed *Throwable* reference 
itself:

 
{noformat}

diff --git 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
index 1e844bb02cb..40f59ad1259 100644
--- 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
+++ 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
@@ -74,7 +74,7 @@ class NettyRpcServerRequestDecoder extends 
ChannelInboundHandlerAdapter {
   public void exceptionCaught(ChannelHandlerContext ctx, Throwable e) {
     allChannels.remove(ctx.channel());
     NettyRpcServer.LOG.trace("Connection {}; caught unexpected downstream 
exception.",
-        ctx.channel().remoteAddress(), e.getCause());
+        ctx.channel().remoteAddress(), e);
     ctx.channel().close();
   }
 }
 {noformat}
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

master branch issues when running with jdk8

[Wellington Chevreuil]

I had faced below errors when trying to run current master branch version
on jdk8 (build was also on jdk8):

2021-05-26T23:02:20,202 TRACE [RS-EventLoopGroup-1-1]
ipc.NettyRpcServer: Connection /192.168.56.105:44592; caught
unexpected downstream exception.
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
> at 
> org.apache.hadoop.hbase.ipc.NettyRpcServerPreambleHandler.channelRead0(NettyRpcServerPreambleHandler.java:48)
>  ~[hbase-server-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
>
>
This specific netty related one happens when RSes try to check into Master,
leaving the cluster unusable, but the same NSME happens at other parts of
the code too, eventually causing processes to crash.

Running on jdk11 fixes it. Anyone else seeing the same? I guess this was
not expected, and our official goal is to still support jdk8 for the
upcoming 3.0 release?

[jira] [Created] (HBASE-25932) TestWALEntryStream#testCleanClosedWALs test is failing.

[Rushabh Shah (Jira)]

Rushabh Shah created HBASE-25932:


 Summary: TestWALEntryStream#testCleanClosedWALs test is failing.
 Key: HBASE-25932
 URL: https://issues.apache.org/jira/browse/HBASE-25932
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 3.0.0-alpha-1, 2.5.0, 2.3.6, 2.4.4
Reporter: Rushabh Shah
Assignee: Rushabh Shah


We are seeing the following test failure. TestWALEntryStream#testCleanClosedWALs
 This test was added in HBASE-25924. I don't think the test failure has 
anything to do with the patch in HBASE-25924.
 Before HBASE-25924, we were *not* monitoring _uncleanlyClosedWAL_ metric. In 
all the branches, we were not parsing the wal trailer when we close the wal 
reader inside ReplicationSourceWALReader thread. The root cause was when we add 
active WAL to ReplicationSourceWALReader, we cache the file size when the wal 
was being actively written and once the wal was closed and replicated and 
removed from WALEntryStream, we did reset the ProtobufLogReader object but we 
didn't update the length of the wal and that was causing EOF errors since it 
can't find the WALTrailer with the stale wal file length.

The fix applied nicely to branch-1 since we use FSHlog implementation which 
closes the WAL file sychronously.

But in branch-2 and master, we use _AsyncFSWAL_ implementation and the closing 
of wal file is done asynchronously (as the name suggests). This is causing the 
test to fail. Below is the test.
{code:java}
  @Test
  public void testCleanClosedWALs() throws Exception {
try (WALEntryStream entryStream = new WALEntryStream(
  logQueue, CONF, 0, log, null, logQueue.getMetrics(), fakeWalGroupId)) {
  assertEquals(0, logQueue.getMetrics().getUncleanlyClosedWALs());
  appendToLogAndSync();
  assertNotNull(entryStream.next());
  log.rollWriter();  ===> This does an asynchronous close of wal.
  appendToLogAndSync();
  assertNotNull(entryStream.next());
  assertEquals(0, logQueue.getMetrics().getUncleanlyClosedWALs());
}
  }
{code}
In the above code, when we roll writer, we don't close the old wal file 
immediately so the ReplicationReader thread is not able to get the updated wal 
file size and that is throwing EOF errors.
 If I added a sleep of few milliseconds (1 ms in my local env) between 
rollWriter and appendToLogAndSync statement then the test passes but this is 
*not* a proper fix since we are working around the race between 
ReplicationSourceWALReaderThread and closing of WAL file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-25931) Move FavoredNodeManager to hbase-balancer module

[Duo Zhang (Jira)]

Duo Zhang created HBASE-25931:
-

 Summary: Move FavoredNodeManager to hbase-balancer module
 Key: HBASE-25931
 URL: https://issues.apache.org/jira/browse/HBASE-25931
 Project: HBase
  Issue Type: Sub-task
  Components: Balancer, FavoredNodes
Reporter: Duo Zhang
Assignee: Duo Zhang
 Fix For: 3.0.0-alpha-1






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-25930) Thrift does not support requests in Kerberos environment

[haoning (Jira)]

haoning created HBASE-25930:
---

 Summary: Thrift does not support requests in Kerberos environment
 Key: HBASE-25930
 URL: https://issues.apache.org/jira/browse/HBASE-25930
 Project: HBase
  Issue Type: Bug
  Components: Thrift
Affects Versions: 2.2.6
Reporter: haoning
 Attachments: image-2021-05-27-20-12-28-164.png, 
image-2021-05-27-20-12-33-818.png

In Kerberos environment, running DemoClient to request thrift server failed

 

!image-2021-05-27-20-12-33-818.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-25926) Cleanup MetaTableAccessor references in FavoredNodeBalancer related code

[Duo Zhang (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-25926.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Pushed to master and branch-2.

Thanks [~niuyulin] for reviewing.

> Cleanup MetaTableAccessor references in FavoredNodeBalancer related code
> 
>
> Key: HBASE-25926
> URL: https://issues.apache.org/jira/browse/HBASE-25926
> Project: HBase
>  Issue Type: Sub-task
>  Components: Balancer, FavoredNodes, meta
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0
>
>
> Actually we do not need to use MetaTableAccessor here, and we do not need to 
> put region info when updating favored node.
> And also the tests need some improvements.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)