Skip to content

HIVE-27126: queue level resource stats for YARN RM. - #6501

Open
architjainjain wants to merge 2 commits into
apache:masterfrom
architjainjain:HIVE-27126-yarn-RM
Open

HIVE-27126: queue level resource stats for YARN RM.#6501
architjainjain wants to merge 2 commits into
apache:masterfrom
architjainjain:HIVE-27126-yarn-RM

Conversation

@architjainjain

@architjainjain architjainjain commented May 20, 2026

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

This PR adds real-time YARN queue resource metrics display alongside Tez job progress during query execution. Users can now see memory, vCores, capacity utilization, running/pending applications, and allocated/pending containers for the queue being used by their queries.

Key Components:

  • YarnQueueMetricsCollector: Collects queue metrics from YARN ResourceManager
  • QueueMetricsCache: JVM-wide shared cache with expiry-based refresh (fetches only when cached data expires)
  • QueueMetricsRefreshPool: Scheduled executor pool for non-blocking metric collection
  • TezProgressMonitor: Enhanced to display queue metrics alongside task progress

What is NOT Changed:

  • Tez query execution logic remains unchanged
  • No modifications to YARN ResourceManager communication protocols
  • DAG submission, task scheduling, and container allocation logic untouched
  • Existing progress monitoring and logging infrastructure preserved

Technical Highlights:

  • Queue-level RM API calls: Single ResourceManager call per queue (not per session), only when cache expires
  • Shared caching: Multiple sessions using the same queue share cached metrics, reducing RM load
  • Dynamic refresh scheduling: Cache automatically adjusts to the lowest refresh interval among all active sessions for a queue
  • Jitter: Random 0-10% delay added to refresh intervals to prevent thundering herd when multiple queues expire simultaneously
  • Circuit breaker: Automatic fallback to no-op collector after 3 consecutive RM failures, preventing cascading failures

Configuration:

  • hive.tez.queue.metrics.refresh.interval: Per-session refresh interval (default: 0s)
  • hive.server2.tez.queue.metrics.refresh.threads: Pool size for metric collection (default: 4)

Important Note: An HTTP exporter and Prometheus/Grafana integration were implemented as a local testing setup to validate the feature during development. These components are NOT part of this PR, NOT included in production code, and were only used in a local Docker environment for validation purposes.

Why are the changes needed?

Currently, when a Hive query is slow or stalled, users cannot determine if the issue is due to insufficient queue resources or other factors. They see Tez task progress (e.g., "Map 1: 3/10") but have no visibility into whether the queue has available memory/vCores to execute tasks in parallel.

This enhancement provides real-time queue resource information, enabling users to:

  • Identify resource bottlenecks immediately (e.g., queue at 95% memory usage)
  • Distinguish between slow queries due to lack of resources vs. data processing overhead
  • Make informed decisions about queue selection or query timing
  • Understand if pending containers are waiting due to queue capacity limits

Backward Compatibility:

  • Fully backward compatible - feature is opt-in via configuration (disabled by default in this implementation, can be enabled by setting refresh interval)
  • When disabled (interval=0s), behavior is identical to previous Hive versions
  • No changes to existing APIs, query execution, or Tez integration
  • No impact on existing queries, scripts, or workflows

Performance Impact:

  • Minimal overhead: Shared cache with single RM call per queue (not per session)
  • Non-blocking: Metrics collected in background thread pool
  • Graceful degradation: Circuit breaker prevents cascading failures
  • Zero impact when disabled

Does this PR introduce any user-facing change?

Yes. When hive.tez.queue.metrics.refresh.interval is set to a positive value (default: 0s), users will see queue-level metrics displayed with Tez job progress:

In-place mode (hive.server2.in.place.progress=true):

Map 1: 3/10   Reducer 2: 0/5
QUEUE: default
MEMORY: 1.5/5.4 GB (27.78% used) | VCORES: 3/7 (42.86% used)
CAPACITY: 46.30% (used), 60.00% (allocated)
APPS: 1 running, 0 pending | CONTAINERS: 4 allocated, 0 pending

Log file mode (hive.server2.in.place.progress=false):

INFO  : Map 1: 3/10   Reducer 2: 0/5    QUEUE: default | MEMORY: 1.5/5.4 GB (27.78% used) | VCORES: 3/7 (42.86% used) | CAPACITY: 46.30% (used), 60.00% (allocated) | APPS: 1 running, 0 pending | CONTAINERS: 4 allocated, 0 pending

When disabled (set hive.tez.queue.metrics.refresh.interval=0s):
No queue metrics are displayed, behavior remains identical to previous versions.

How was this patch tested?

The patch was tested in a multi-node YARN cluster environment with concurrent queries running on different queues.

Testing included:

  1. Functional testing: Queue metrics displayed correctly with various refresh intervals (1s, 5s, 10s)
  2. Feature toggle testing: Metrics disabled when refresh interval set to 0s
  3. Multi-session testing: Multiple concurrent sessions with different queues and refresh intervals
  4. Dynamic scheduling: Verified cache adjusts to lowest interval when sessions with different settings share a queue
  5. Cross-mode testing: Verified consistent output in both in-place and log file modes
  6. Performance testing: Validated minimal overhead with shared cache and background refresh pool
  7. Efficiency validation: Confirmed single RM API call per queue (not per session) only on cache expiry
  8. Jitter behavior: Verified 0-10% randomization prevents simultaneous refresh across queues
  9. Circuit breaker: Validated automatic failover to no-op collector after consecutive RM failures

Test Environment:

  • YARN cluster with multiple queues (default, analytics, batch)
  • HiveServer2 with Tez execution engine
  • Concurrent query workloads

Validation artifacts (local testing setup only - NOT in production):

  • Prometheus exporter and Grafana dashboards were implemented in a local Docker environment to validate metric accuracy, cache behavior, and refresh scheduling
  • Multi-session test scripts for concurrent scenario validation
  • These testing tools are separate from the production code and not included in this PR

Screenshots:

1. Terminal output with queue metrics enabled (hive.tez.queue.metrics.refresh.interval=10s):

Queue metrics showing memory, vcores, capacity, apps and containers alongside Tez progress

2. Terminal output with queue metrics disabled (hive.tez.queue.metrics.refresh.interval=0s):

Query progress without queue metrics, showing only Tez task progress

3. Grafana dashboard showing backend metrics validation (local testing setup only):

Screenshot 2026-07-22 at 11 29 39 AM

Note: The Grafana and Prometheus infrastructure shown above was created exclusively for local testing and validation purposes. This monitoring stack is NOT part of the production code, NOT included in the deployment, and was only used in a local Docker environment to validate the feature's correctness.

Configuration tested:

<!-- Enable queue metrics with 10-second refresh -->
<property>
  <name>hive.tez.queue.metrics.refresh.interval</name>
  <value>10s</value>
</property>

<!-- Disable queue metrics -->
<property>
  <name>hive.tez.queue.metrics.refresh.interval</name>
  <value>0s</value>
</property>

@abstractdog abstractdog 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.

thanks @architjainjain so far, dropped some comments, but I wasn't able to fully read it through, I'll get back after, in the meantime I can do some testing too hopefully

* behaviour added as part of HIVE-27126.
*
* We capture stdout via a ByteArrayOutputStream and inspect the rendered output.
*/public class TestInPlaceUpdate {

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.

line break before public

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

done

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.

TestInPlaceUpdate disappeared in the meantime from the PR
if it's not needed anymore, feel free to resolve this comment, otherwise I'm happy to see that test case

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I have added back, test case.

Comment thread common/src/test/org/apache/hadoop/hive/common/log/TestInPlaceUpdate.java Outdated
Comment thread common/src/test/org/apache/hadoop/hive/common/log/TestInPlaceUpdate.java Outdated
Comment thread common/src/test/org/apache/hadoop/hive/common/log/TestInPlaceUpdate.java Outdated
Comment thread common/src/test/org/apache/hadoop/hive/common/log/TestInPlaceUpdate.java Outdated
Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestYarnQueueMetricsCollector.java Outdated
Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestYarnQueueMetricsCollector.java Outdated
Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestYarnQueueMetricsCollector.java Outdated
Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestYarnQueueMetricsCollector.java Outdated
Comment on lines +824 to +830
// HIVE-27126: Thrift regeneration omitted setStartTimeIsSet(true) from the constructor.
// Explicitly call setStartTime() to set the isset flag required for Thrift validation.
tProgressUpdateResp.setStartTime(progressUpdate.startTimeMillis);
if (progressUpdate.queueMetrics() != null && !progressUpdate.queueMetrics().isEmpty()) {
tProgressUpdateResp.setQueueMetrics(progressUpdate.queueMetrics());
}
resp.setProgressUpdateResponse(tProgressUpdateResp);

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.

why is this change needed?

@architjainjain architjainjain Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This works around a Thrift code generation bug. When we regenerated Thrift code after adding the queueMetrics field, the generated constructor for TProgressUpdateResp accepts startTimeMillis but fails to set the isset flag. Without this flag, Thrift serialization treats the field as unset, causing clients to receive incomplete progress updates. The explicit setStartTime() call ensures both the value AND the isset flag are properly set, maintaining backward compatibility with Thrift clients.

without this test the generated file is not having the starttime isset flag updated.

https://github.com/apache/hive/pull/6501/changes#diff-d71ddeafeea57e0fbf6a9dfda436eab06b69a39ac46c815cc1b15bfffe5f35e0L155

this.status = status;
this.footerSummary = footerSummary;
this.startTime = startTime;
setStartTimeIsSet(true);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@abstractdog this is getting removed. so we added manually after the constructor call.

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.

this is not expected, see my other comment thrift code generation
https://github.com/apache/hive/pull/6501/changes#r3703255649

Copilot AI 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.

Pull request overview

Note

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Adds optional, real-time YARN queue resource metrics to the Tez progress display during Hive query execution, propagating the data through HS2/Thrift and Beeline in-place updates.

Changes:

  • Introduces YARN queue metrics collection (collector + per-queue state + shared cache + scheduled refresh pool with jitter/circuit breaker).
  • Integrates queue metrics into Tez progress rendering (in-place + log-to-file) and publishes it over Thrift (TProgressUpdateResp).
  • Adds unit tests covering cache/state/pool behavior and Tez monitor formatting/initialization.

Reviewed changes

Copilot reviewed 29 out of 30 changed files in this pull request and generated 9 comments.

Show a summary per file
File Description
service/src/java/org/apache/hive/service/server/HiveServer2.java Initializes the shared refresh pool during HS2 Tez session pool startup.
service/src/java/org/apache/hive/service/cli/thrift/ThriftCLIService.java Populates new Thrift queueMetrics field and applies Thrift “isset” workaround for startTime.
service/src/java/org/apache/hive/service/cli/JobProgressUpdate.java Adds queue metrics string to progress update model.
service-rpc/if/TCLIService.thrift Adds optional queueMetrics to TProgressUpdateResp.
ql/src/java/org/apache/hadoop/hive/ql/session/SessionState.java Implements queueMetrics() default for the progress monitor facade.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/QueueMetricsCollector.java New interface for queue metrics collectors.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/NoOpQueueMetricsCollector.java Null-object collector when feature is disabled.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/QueueMetricsSnapshot.java Immutable snapshot of queue resource stats fetched from RM.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/QueueMetricsState.java Per-queue state: interval registration, scheduling, refresh lock, circuit breaker.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/QueueMetricsCache.java JVM-wide Guava cache mapping queue name → state with expiry.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/QueueMetricsRefreshPool.java JVM-wide scheduled executor singleton to run refresh tasks (with jitter).
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/YarnQueueMetricsCollector.java Active collector that coordinates with shared cache/state and refresh pool.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/TezProgressMonitor.java Formats and returns multi-line queue metrics for progress rendering.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/TezJobMonitor.java Creates/shuts down the metrics collector based on config and wires it into progress monitor.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/monitoring/RenderStrategy.java Appends queue metrics into log-to-file progress report (single-line rendering).
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezSessionState.java Adds per-session YarnClient lifecycle to support collector RM queries.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezSessionPoolSession.java Exposes YarnClient via pooled session wrapper.
ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezSession.java Extends TezSession interface with getYarnClient().
common/src/java/org/apache/hadoop/hive/conf/HiveConf.java Adds new configuration keys for refresh interval and refresh thread pool size.
common/src/java/org/apache/hadoop/hive/common/log/ProgressMonitor.java Adds queueMetrics() to the ProgressMonitor contract.
common/src/java/org/apache/hadoop/hive/common/log/InPlaceUpdate.java Renders queue metrics block (multi-line) under the standard progress output.
beeline/src/java/org/apache/hive/beeline/logs/BeelineInPlaceUpdateStream.java Reads queueMetrics from Thrift progress updates for in-place rendering.
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/monitoring/yarnqueue/TestQueueMetricsState.java Unit tests for per-queue state logic (intervals, refresh lock, circuit breaker).
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/monitoring/TestTezProgressMonitorQueueMetrics.java Unit tests for queue metrics formatting and edge cases in TezProgressMonitor.
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/monitoring/TestTezJobMonitorQueueMetrics.java Unit tests for TezJobMonitor collector initialization decisions.
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestYarnQueueMetricsCollector.java Unit tests for collector/cache/pool integration behavior and circuit breaker.
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestQueueMetricsRefreshPool.java Unit tests for refresh pool singleton, scheduling, and jitter determinism/range.
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestQueueMetricsCache.java Unit tests for cache placeholder/put semantics and concurrency behavior.
ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestNoOpQueueMetricsCollector.java Unit tests for NoOp collector behavior and singleton semantics.
Files not reviewed (1)
  • service-rpc/src/gen/thrift/gen-javabean/org/apache/hive/service/rpc/thrift/TProgressUpdateResp.java: Generated file

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezSessionState.java Outdated
Comment thread service/src/java/org/apache/hive/service/server/HiveServer2.java
Comment thread service/src/java/org/apache/hive/service/server/HiveServer2.java
Comment thread common/src/java/org/apache/hadoop/hive/conf/HiveConf.java

@abstractdog abstractdog 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.

thanks @architjainjain for the patch so far, left comments

if (System.currentTimeMillis() - startTime > timeoutMs) {
fail("Snapshot not available after " + timeoutMs + "ms");
}
Thread.onSpinWait(); // Hint to JVM that this is a spin-wait loop

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.

I believe onSpinWait is just a sophisticated way to "busy wait", and in unit tests, there always must be a better way leveraging CountDownLatch, CyclicBarrier, this applies to other usages of Thread.onSpinWait

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

replaced all Thread.onSpinWait() usages with Thread.sleep(10), which properly yields the CPU to other threads (including the background refresh thread) between each poll, rather than busy-waiting.
For the async scenarios (waitForSnapshot, waitForInvocationCount, post-shutdown stabilization), the polling loop with Thread.sleep(10) is the right approach since these results are driven by the background scheduled executor — there's no test-owned thread to coordinate with a CountDownLatch or CyclicBarrier without adding test hooks to production code.
CountDownLatch/CyclicBarrier are already used correctly in TestQueueMetricsCache for testConcurrentPutPlaceholderRaces and testConcurrentPutAndGetNoDeadlock, where the test itself creates and coordinates multiple threads — which is exactly the right use case for those primitives.

if (System.currentTimeMillis() - startTime > timeoutMs) {
return;
}
Thread.onSpinWait(); // Hint to JVM that this is a spin-wait loop

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

done

long deadline = System.currentTimeMillis() + 3000;
do {
callsAfterShutdown = mockingDetails(mockYarnClient).getInvocations().size();
Thread.onSpinWait(); // Hint to JVM that this is a spin-wait loop

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

done

// Spin-wait up to 200ms to ensure time has passed so the age comparison is meaningful
long deadline = System.currentTimeMillis() + 200;
while (state.getAgeMs() <= initialAge && System.currentTimeMillis() < deadline) {
Thread.onSpinWait(); // Hint to JVM that this is a spin-wait loop

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.

Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestYarnQueueMetricsCollector.java Outdated
Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestTezSessionState.java Outdated
Comment thread ql/src/test/org/apache/hadoop/hive/ql/exec/tez/TestTezSessionState.java Outdated
Comment on lines +228 to +257
// Create multiple threads that call getYarnClient() concurrently
final int threadCount = 10;
Thread[] threads = new Thread[threadCount];
YarnClient[] clients = new YarnClient[threadCount];

for (int i = 0; i < threadCount; i++) {
final int index = i;
threads[i] = new Thread(() -> {
clients[index] = sessionState.getYarnClient();
});
}

// Start all threads
for (Thread thread : threads) {
thread.start();
}

// Wait for all threads to complete
for (Thread thread : threads) {
thread.join();
}

// All threads should get the same YarnClient instance
YarnClient firstClient = clients[0];
Assert.assertNotNull("YarnClient should be initialized", firstClient);

for (int i = 1; i < threadCount; i++) {
Assert.assertSame("All threads should get the same YarnClient instance", firstClient, clients[i]);
}
}

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.

I don't think we have to write "thread creation and wait" from scratch, what about something like this:

    int threadCount = 10;
    ExecutorService executor = Executors.newFixedThreadPool(threadCount);
    CountDownLatch start = new CountDownLatch(1);

    try {
        List<Future<YarnClient>> futures = IntStream.range(0, threadCount)
            .mapToObj(i -> executor.submit(() -> {
                start.await();
                return sessionState.getYarnClient();
            }))
            .collect(Collectors.toList());

        start.countDown();

        YarnClient firstClient = futures.get(0).get();
        assertNotNull("YarnClient should be initialized", firstClient);

        for (Future<YarnClient> future : futures) {
            assertSame(
                "All threads should get the same YarnClient instance",
                firstClient,
                future.get());
        }
    } finally {
        executor.shutdownNow();
    }

CountDownLatch also helps testing high concurrency

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

done

this.status = status;
this.footerSummary = footerSummary;
this.startTime = startTime;
setStartTimeIsSet(true);

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.

this is not expected, see my other comment thrift code generation
https://github.com/apache/hive/pull/6501/changes#r3703255649

@abstractdog abstractdog 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.

thanks @architjainjain for the patch so far, left comments

@architjainjain

Copy link
Copy Markdown
Contributor Author

thanks @architjainjain for the patch so far, left comments

I will look into this and provide fix for the review comments added.

* queue metrics is controlled per-session by {@code hive.tez.queue.metrics.refresh.interval},
* which is checked when creating metrics collectors for each query.
* <p>
* In non-Tez environments (MR, Spark, local), the pool is not created, avoiding unnecessary

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@@ -0,0 +1,247 @@
/*

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@abstractdog This is the new test case added

@architjainjain architjainjain left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@abstractdog All commnets are addressed and updated/added/removed test case as per the changes.
Thanks for the review.

@sonarqubecloud

sonarqubecloud Bot commented Aug 6, 2026

Copy link
Copy Markdown

private static final int DEFAULT_THREAD_COUNT = 4;
public static final int JITTER_PERCENT = 10;

private static final AtomicReference<QueueMetricsRefreshPool> instance = new AtomicReference<>(null);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@abstractdog you comment was regarding usage of AtomicReference, and only volatile can be sufficient.

Switched to AtomicReference because:
volatile alone isn't thread-safe for compound operations - The check-then-act pattern (if (instance == null) instance = new...) requires synchronization
AtomicReference provides atomic compare-and-set - Single atomic operation vs. separate check + lock + set
Lock-free - No thread blocking, better for concurrent HiveServer2 startup
Explicit concurrency handling - compareAndSet() makes race condition handling visible in code
The original volatile + synchronized was correct but required locks. AtomicReference achieves thread-safety without blocking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants