CAMEL-24003: Add heap dump command to CLI, TUI, and MCP#24663
Conversation
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet
left a comment
There was a problem hiding this comment.
Review: CAMEL-24003 - Add heap dump command to CLI, TUI, and MCP
Nice feature addition. The implementation is well-structured and follows the established patterns for dev consoles, CLI commands, TUI integration, and MCP/AI tool registration. The layered approach (dev console -> CLI connector -> jbang command / TUI / MCP) is consistent with how heap-histogram, memory-leak, and other diagnostic features work.
A few items worth discussing:
Findings
1. [Medium] Direct compile-time dependency on com.sun.management.HotSpotDiagnosticMXBean (HeapDumpDevConsole.java)
The existing HeapHistogramDevConsole avoids a compile-time dependency on com.sun.management by using string-based MBean lookup (new ObjectName("com.sun.management:type=DiagnosticCommand")). The new HeapDumpDevConsole directly imports com.sun.management.HotSpotDiagnosticMXBean, which creates a hard compile-time dependency on HotSpot-internal API. This could cause NoClassDefFoundError on alternative JVMs (e.g., OpenJ9, GraalVM native image). Consider using the MXBean via ManagementFactory.getPlatformMBeanServer() and string-based invocation instead, or at minimum wrap the call so it degrades gracefully.
2. [Low] No input sanitization on dump file name (HeapDumpDevConsole.java)
The user-supplied name parameter is passed directly to bean.dumpHeap(name, live) after only appending .hprof. A value like ../../tmp/evil would write to an arbitrary path. Per Camel's security model, CLI/TUI users are trusted (they already have JVM-level access), so this is low severity. Still, stripping path separators or using Path.getFileName() would be a reasonable defensive measure.
3. [Low] Code duplication of triggerHeapDump() and notify() between MemoryTab and MemoryLeakTab
Both tabs contain nearly identical ~40-line triggerHeapDump() and notify() methods. The MemoryLeakTab version uses its existing startDaemonThread() helper, while MemoryTab creates the daemon thread inline. Consider extracting the shared logic to a utility (or a default method on a shared base) to avoid drift between the two copies.
4. [Low] No test coverage (project-wide)
No tests were added. While the existing HeapHistogramDevConsole also has no test, the project's CLAUDE.md states: "Every PR must include tests for new functionality or bug fixes." A basic unit test for the dev console (e.g., verifying JSON output shape, error propagation, default filename generation) would be straightforward and valuable.
5. [Info] MCP tool uses runtimeService.executeAction() directly instead of delegateToRegistry()
The adjacent camel_runtime_heap_histogram delegates via delegateToRegistry("get_heap_histogram", ...) while the new camel_runtime_heap_dump calls runtimeService.executeAction() directly. This is fine since heap dump needs custom parameter forwarding, but it is a pattern difference worth noting for consistency.
Summary
The feature is well-designed and the code is clean. The main item to consider is the direct com.sun.management import which introduces a HotSpot-specific compile dependency, unlike the existing heap histogram console which avoids it. The other findings are minor suggestions.
Scanner coverage
No static analysis tools (SonarCloud, SpotBugs, Error Prone) were executed as part of this review. This review does not replace those tools or specialized AI review tools like CodeRabbit.
Claude Code review on behalf of @gnodet
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
|
Thanks for the review @gnodet! All three inline findings have been addressed in 17b46ab:
On the remaining items:
|
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…eaks Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…r hints Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
b5351a4 to
4b015be
Compare
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 17 tested, 26 compile-only — current: 14 all testedMaveniverse Scalpel detected 43 affected modules (current approach: 14).
|
Summary
Claude Code on behalf of davsclaus
camel cmd heap-dumpCLI command to write.hprofheap dump files from a running Camel integration for deep memory analysis with tools like Eclipse MAT or VisualVMHeapDumpDevConsolein camel-console as the server-side implementation usingHotSpotDiagnosticMXBeanLocalCliConnectorto bridge CLI/TUI requests to the dev consolehkey shortcutwrite_heap_dumpAI tool andcamel_runtime_heap_dumpMCP toolTest plan
camel cmd heap-dumpagainst a running integration and verify.hproffile is createdcamel cmd heap-dump --dump-name=test --live=falseand verify options workh, verify heap dump is written and notification appearsh, verify heap dump is written and notification appearscamel_runtime_heap_dumpworks via MCP client🤖 Generated with Claude Code