Skip to content

HBASE-29372: Meta cache clear metrics and logs shouldn't use "UnknownException" - #6961

Merged
rmdmattingly merged 1 commit into
apache:branch-2from
hgromer:HBASE-29265
Jun 4, 2025
Merged

HBASE-29372: Meta cache clear metrics and logs shouldn't use "UnknownException"#6961
rmdmattingly merged 1 commit into
apache:branch-2from
hgromer:HBASE-29265

Conversation

@hgromer

Copy link
Copy Markdown
Contributor

No description provided.

@hgromer
hgromer marked this pull request as draft May 5, 2025 17:53
@hgromerhgromer changed the title HBASE-29265: Operation timeouts can create a pathological feedback loop with multigetsHBASE-29265: Batch calls to overloaded cluster can cause meta hotspottingMay 5, 2025
@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@hgromer
hgromer marked this pull request as ready for review May 6, 2025 14:11
if (clearServerCache) {
updateCachedLocations(server, regionName, row,
ClientExceptionsUtil.isMetaClearingException(t) ? null : t);
updateCachedLocations(server, regionName, row, t);

@hgromerhgromerMay 6, 2025

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also solves the frustration of seeing "UnknownException" when inspecting meta cache clear exception metrics. This has made it quite difficult to track down what triggered the meta cache clear.

I think it's always better to provide more context than less. Even if an exception is meta cache clearing (though it will be now), I'd still prefer to know the exact exception type that cleared the meta cache.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 would be good to preserve the exception for updateCachedLocations

Since we currently pass null to updateCachedLocations if we have a meta cache clearing exception, does that means that we never update the cache clearing exception metric properly for cache clears coming from receiveGlobalFailure?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we'll do is basically "mask" the cache clearing exception by report an UnknownException. The code for that lives in the metrics class. It's annoying b/c that coupled with the lack of any logging in this code path makes it really difficult to determine what caused these meta cache clears.

@hgromer

Copy link
Copy Markdown
ContributorAuthor

Retry canRetry = errorsByServer.canTryMore(numAttempt) ? Retry.YES : Retry.NO_RETRIES_EXHAUSTED;
boolean clearServerCache = false;

if (!(t instanceof RejectedExecutionException)) {

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enforces the constraints added in https://issues.apache.org/jira/browse/HBASE-27491

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better if you instead push RejectedExecutionException down into ClientExceptionsUtil.isMetaClearingException.

How about adding another collection of execution-exceptions for the family of various ExecutorService interaction errors, like is done with networking/connection exceptions?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted, adding that

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hgromer I think you dropped my earlier comment.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

if (clearServerCache) {
updateCachedLocations(server, regionName, row,
ClientExceptionsUtil.isMetaClearingException(t) ? null : t);
updateCachedLocations(server, regionName, row, t);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 would be good to preserve the exception for updateCachedLocations

Since we currently pass null to updateCachedLocations if we have a meta cache clearing exception, does that means that we never update the cache clearing exception metric properly for cache clears coming from receiveGlobalFailure?

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@droudnitskydroudnitsky left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the new scope of the work is

  1. Pass the meta clearing exception to updateCachedLocations so we can properly capture the exception in the client metric instead of unknown exception
  2. Pushing RejectedExecutionException down into isMetaClearingException

I am wondering if it make sense to split these into two different issues given the change in scope? My initial thought is in agreement that RejectedExecutionException should not be meta cache clearing, but maybe it would be beneficial to handle that change independently of the client metric fix , there may be implications beyond batch operations for that change.

@hgromer

Copy link
Copy Markdown
ContributorAuthor

Looks like the new scope of the work is

  1. Pass the meta clearing exception to updateCachedLocations so we can properly capture the exception in the client metric instead of unknown exception
  2. Pushing RejectedExecutionException down into isMetaClearingException

I am wondering if it make sense to split these into two different issues given the change in scope? My initial thought is in agreement that RejectedExecutionException should not be meta cache clearing, but maybe it would be beneficial to handle that change independently of the client metric fix , there may be implications beyond batch operations for that change.

It'd make sense for me to have that be it's own thing (one I probably wouldn't own to be completely honest), cc @ndimiduk since I was following his suggestion

@hgromerhgromer changed the title HBASE-29265: Batch calls to overloaded cluster can cause meta hotspottingHBASE-29265: Meta cache clear metrics and logs shouldn't use "UnknownException"May 29, 2025
@hgromer

Copy link
Copy Markdown
ContributorAuthor

I've updated the PR to soleley add some logging and emitting the real meta cache clearing exception in meta cache clear metrics. cc @ndimiduk@droudnitsky

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@hgromer

Copy link
Copy Markdown
ContributorAuthor

The hadoopcheck issue seems unrelated

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 44sDocker mode activated.
-0 ⚠️yetus0m 5sUnprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
_ Prechecks _
_ branch-2 Compile Tests _
+1 💚mvninstall3m 20sbranch-2 passed
+1 💚compile0m 19sbranch-2 passed
+1 💚javadoc0m 17sbranch-2 passed
+1 💚shadedjars5m 31sbranch has no errors when building our shaded downstream artifacts.
_ Patch Compile Tests _
+1 💚mvninstall2m 30sthe patch passed
+1 💚compile0m 20sthe patch passed
+1 💚javac0m 20sthe patch passed
+1 💚javadoc0m 16sthe patch passed
+1 💚shadedjars5m 28spatch has no errors when building our shaded downstream artifacts.
_ Other Tests _
+1 💚unit7m 58shbase-client in the patch passed.
27m 51s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile
GITHUB PR#6961
JIRA IssueHBASE-29265
Optional Testsjavac javadoc unit compile shadedjars
unameLinux c3ae91027442 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionbranch-2 / d138309
Default JavaTemurin-1.8.0_412-b08
Test Resultshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/testReport/
Max. process+thread count366 (vs. ulimit of 30000)
modulesC: hbase-client U: hbase-client
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/console
versionsgit=2.34.1 maven=3.9.8
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 52sDocker mode activated.
_ Prechecks _
+1 💚dupname0m 0sNo case conflicting files found.
+0 🆗codespell0m 0scodespell was not available.
+0 🆗detsecrets0m 0sdetect-secrets was not available.
+1 💚@author0m 0sThe patch does not contain any @author tags.
+1 💚hbaseanti0m 0sPatch does not have any anti-patterns.
_ branch-2 Compile Tests _
+1 💚mvninstall3m 32sbranch-2 passed
+1 💚compile0m 56sbranch-2 passed
+1 💚checkstyle0m 31sbranch-2 passed
+1 💚spotbugs1m 15sbranch-2 passed
+1 💚spotless1m 3sbranch has no errors when running spotless:check.
_ Patch Compile Tests _
+1 💚mvninstall3m 48sthe patch passed
+1 💚compile1m 4sthe patch passed
+1 💚javac1m 4sthe patch passed
+1 💚blanks0m 1sThe patch has no blanks issues.
+1 💚checkstyle0m 25sthe patch passed
+1 💚spotbugs1m 13sthe patch passed
+1 💚hadoopcheck20m 38sPatch does not cause any errors with Hadoop 2.10.2 or 3.3.6 3.4.0.
+1 💚spotless1m 21spatch has no errors when running spotless:check.
_ Other Tests _
+1 💚asflicense0m 16sThe patch does not generate ASF License warnings.
39m 10s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/artifact/yetus-general-check/output/Dockerfile
GITHUB PR#6961
JIRA IssueHBASE-29265
Optional Testsdupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless
unameLinux 8cf4818e13ab 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionbranch-2 / d138309
Default JavaEclipse Adoptium-11.0.23+9
Max. process+thread count79 (vs. ulimit of 30000)
modulesC: hbase-client U: hbase-client
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/console
versionsgit=2.34.1 maven=3.9.8 spotbugs=4.7.3
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 55sDocker mode activated.
-0 ⚠️yetus0m 5sUnprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
_ Prechecks _
_ branch-2 Compile Tests _
+1 💚mvninstall3m 53sbranch-2 passed
+1 💚compile0m 27sbranch-2 passed
+1 💚javadoc0m 22sbranch-2 passed
+1 💚shadedjars7m 12sbranch has no errors when building our shaded downstream artifacts.
_ Patch Compile Tests _
+1 💚mvninstall3m 33sthe patch passed
+1 💚compile0m 23sthe patch passed
+1 💚javac0m 23sthe patch passed
+1 💚javadoc0m 19sthe patch passed
+1 💚shadedjars6m 59spatch has no errors when building our shaded downstream artifacts.
_ Other Tests _
+1 💚unit7m 56shbase-client in the patch passed.
33m 13s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile
GITHUB PR#6961
JIRA IssueHBASE-29265
Optional Testsjavac javadoc unit compile shadedjars
unameLinux b5185e8fb582 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionbranch-2 / d138309
Default JavaEclipse Adoptium-11.0.23+9
Test Resultshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/testReport/
Max. process+thread count367 (vs. ulimit of 30000)
modulesC: hbase-client U: hbase-client
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/console
versionsgit=2.34.1 maven=3.9.8
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 41sDocker mode activated.
-0 ⚠️yetus0m 5sUnprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
_ Prechecks _
_ branch-2 Compile Tests _
+1 💚mvninstall3m 21sbranch-2 passed
+1 💚compile0m 23sbranch-2 passed
+1 💚javadoc0m 18sbranch-2 passed
+1 💚shadedjars6m 21sbranch has no errors when building our shaded downstream artifacts.
_ Patch Compile Tests _
+1 💚mvninstall3m 7sthe patch passed
+1 💚compile0m 23sthe patch passed
+1 💚javac0m 23sthe patch passed
+1 💚javadoc0m 17sthe patch passed
+1 💚shadedjars6m 20spatch has no errors when building our shaded downstream artifacts.
_ Other Tests _
+1 💚unit8m 15shbase-client in the patch passed.
30m 32s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR#6961
JIRA IssueHBASE-29265
Optional Testsjavac javadoc unit compile shadedjars
unameLinux 8ef610a3672c 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionbranch-2 / d138309
Default JavaEclipse Adoptium-17.0.11+9
Test Resultshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/testReport/
Max. process+thread count371 (vs. ulimit of 30000)
modulesC: hbase-client U: hbase-client
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6961/5/console
versionsgit=2.34.1 maven=3.9.8
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@ndimidukndimiduk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is devilishly difficult to follow. There's a complex commit history around this behavior that includes attempted refactors and reverts. It seems like the test harness is pretty good at catching issues though.

It looks like you're partially undoing #4914, which I think is fine. Reading though that PR, I believe the correct implementation would have been to push knowledge of the RejectedExecutionException down into ClientExceptionsUtil#isMetaClearingException(). Instead it externalised the logic up here in AsyncRequestFutureImpl, making it more difficult to follow. I think you haven't done enough and should go ahead and push the exception check down further.

Do you have any suggestions for we we verify that this exception/null pass-down hasn't subtly broken something?

Retry canRetry = errorsByServer.canTryMore(numAttempt) ? Retry.YES : Retry.NO_RETRIES_EXHAUSTED;
boolean clearServerCache;

if (t instanceof RejectedExecutionException) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should add RejectedExecutionException to the predicate in ClientExceptionsUtil#isMetaClearingException(). Seems dicy to have a special case test here. Or am I missing some wider context?

@ndimiduk
ndimiduk requested a review from Apache9June 3, 2025 09:25
@ndimiduk

Copy link
Copy Markdown
Member

Looks like the new scope of the work is

  1. Pass the meta clearing exception to updateCachedLocations so we can properly capture the exception in the client metric instead of unknown exception
  2. Pushing RejectedExecutionException down into isMetaClearingException

I am wondering if it make sense to split these into two different issues given the change in scope? My initial thought is in agreement that RejectedExecutionException should not be meta cache clearing, but maybe it would be beneficial to handle that change independently of the client metric fix , there may be implications beyond batch operations for that change.

It'd make sense for me to have that be it's own thing (one I probably wouldn't own to be completely honest), cc @ndimiduk since I was following his suggestion

Oh. I see now that you and droudnitsky are attempting to cut scope. I don't feel great about leaving the RejectedExecutionException as it is, but if you'd prefer to isolate that change, then let's proceed with what you have.

@ndimiduk

Copy link
Copy Markdown
Member

The refactor on #578 looked like a good effort. Too bad it had to be reverted.

@droudnitskydroudnitsky left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ndimiduk I agree it would have made sense for #4914 to introduce the change through isMetaClearingException. My suggestion to split the scope here is driven by the complexity in this codepath , my thinking being that it'd be easier to reason about the metrics fix and pushing RejectedExecutionException down into isMetaClearingException in two seperate PRs, the latter change is wider in scope. I cannot think of any reason not to push the exception down into isMetaClearingException but it may benefit from some thinking/review independent of the metrics fix, thats just my personal thought.

Looks good to me thank you Hernan

@ndimiduk

Copy link
Copy Markdown
Member

Okay fair enough, let's take this as it is.

@hgromerhgromer changed the title HBASE-29265: Meta cache clear metrics and logs shouldn't use "UnknownException"HBASE-29372: Meta cache clear metrics and logs shouldn't use "UnknownException"Jun 4, 2025
@rmdmattingly
rmdmattingly merged commit 6fb44d0 into apache:branch-2Jun 4, 2025
hgromer added a commit to HubSpot/hbase that referenced this pull request Jun 4, 2025
…xception" (apache#6961)
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
hgromer added a commit to HubSpot/hbase that referenced this pull request Jun 4, 2025
…xception" (apache#6961)
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
hgromer added a commit to HubSpot/hbase that referenced this pull request Jun 4, 2025
…xception" (apache#6961)
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
hgromer added a commit to HubSpot/hbase that referenced this pull request Jun 4, 2025
…xception" (apache#6961) (#180)
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
charlesconnell pushed a commit to HubSpot/hbase that referenced this pull request Jun 25, 2025
…xception" (apache#6961) (#180)
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
charlesconnell pushed a commit to HubSpot/hbase that referenced this pull request Jul 1, 2025
…xception" (apache#6961) (#180)
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
mokai87 pushed a commit to mokai87/hbase that referenced this pull request Aug 7, 2025
…xception" (apache#6961)
Co-authored-by: Hernan Gelaf-Romer <hgelafromer@hubspot.com>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Ray Mattingly <rmattingly@apache.org>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@hgromer@Apache-HBase@ndimiduk@Apache9@rmdmattingly@droudnitsky