Fix direct_memory_bytes in Flight stats to report actual direct buffer usage

[bowenlan-amzn]

Description

The direct_memory_bytes field in /_flight/stats currently reports JVM non-heap memory (MemoryMXBean.getNonHeapMemoryUsage().getUsed()) which includes metaspace, code cache, and compressed class space — not actual direct ByteBuffer allocations.

The fallback path (Runtime.totalMemory() - freeMemory()) reports heap usage, which is also incorrect.

This PR replaces it with BufferPoolMXBean filtered on the "direct" pool, which correctly reports memory allocated via ByteBuffer.allocateDirect().

Context

While analyzing Flight memory accounting, we found this stat is misleading for operators trying to understand actual direct memory pressure from gRPC/Netty framing. The Arrow allocator stats (arrow_allocated_bytes) are correct — only direct_memory_bytes was wrong.

Check List

• New functionality includes testing
• New functionality has been documented
• API changes companion pull request - n/a
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 8977126)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Missing Pool Check If no "direct" pool is found in the iteration, directMemoryBytes remains 0 without distinguishing between "pool not found" and "pool found with 0 bytes used". On JVMs where the direct pool exists but is named differently or unavailable, this silently reports 0 instead of indicating the metric is unavailable. Consider logging a warning or using a sentinel value when the pool is not found. for (java.lang.management.BufferPoolMXBean pool : java.lang.management.ManagementFactory.getPlatformMXBeans( java.lang.management.BufferPoolMXBean.class )) { if ("direct".equals(pool.getName())) { directMemoryBytes = pool.getMemoryUsed(); break; } }

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 8977126

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Log exception when retrieving memory fails Silently catching all exceptions and setting directMemoryBytes to 0 may hide critical issues. Consider logging the exception to aid debugging and monitoring, especially since this metric is important for tracking direct buffer usage. plugins/arrow-flight-rpc/src/main/java/org/opensearch/arrow/flight/stats/FlightStatsCollector.java [128-130] } catch (Exception e) { + logger.warn("Failed to retrieve direct buffer pool memory usage", e); directMemoryBytes = 0; } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that silently catching exceptions can hide issues. Adding logging would improve observability and debugging capabilities for memory metric collection failures. However, this is not a critical bug but rather a best practice improvement.	Medium

---

Previous suggestions

Suggestions up to commit 9fd628c

Category	Suggestion	Impact
General	Log exception when retrieving buffer statistics Silently catching all exceptions and setting directMemoryBytes to 0 may hide critical issues. Consider logging the exception to aid debugging and monitoring, especially since this metric is important for tracking direct buffer usage. plugins/arrow-flight-rpc/src/main/java/org/opensearch/arrow/flight/stats/FlightStatsCollector.java [128-130] } catch (Exception e) { + logger.warn("Failed to retrieve direct buffer pool statistics", e); directMemoryBytes = 0; } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that silently catching exceptions can hide issues. Adding logging would improve observability and debugging capabilities. However, this is a monitoring/observability improvement rather than a critical bug fix, and the fallback to 0 is reasonable for metrics collection.	Medium

Suggestions up to commit 8bec5e7

Category	Suggestion	Impact
General	Log exception when retrieving memory fails Silently catching all exceptions and setting directMemoryBytes to 0 can hide critical issues. Consider logging the exception to aid debugging and monitoring, especially since this metric is important for tracking direct buffer usage. plugins/arrow-flight-rpc/src/main/java/org/opensearch/arrow/flight/stats/FlightStatsCollector.java [128-130] } catch (Exception e) { + logger.warn("Failed to retrieve direct buffer memory usage", e); directMemoryBytes = 0; } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that silently catching exceptions can hide issues. Adding logging would improve observability and debugging capabilities. However, this is not a critical bug but rather a best practice improvement for monitoring and troubleshooting.	Medium

[github-actions]

❌ Gradle check result for 8bec5e7: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 9fd628c

[github-actions]

❌ Gradle check result for 9fd628c: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 8977126

[github-actions]

✅ Gradle check result for 8977126: SUCCESS

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.45%. Comparing base (ca22376) to head (8977126).

Files with missing lines	Patch %	Lines
...earch/arrow/flight/stats/FlightStatsCollector.java	66.66%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##               main   #21769    +/-   ##
==========================================
  Coverage     73.44%   73.45%            
+ Complexity    75084    75063    -21     
==========================================
  Files          6016     6016            
  Lines        341072   341075     +3     
  Branches      49091    49093     +2     
==========================================
+ Hits         250513   250526    +13     
+ Misses        70641    70528   -113     
- Partials      19918    20021   +103     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.