How do you troubleshoot memory leaks caused by unclosed StAX builders in Axiom?

An unclosed StAXOMBuilder (or the XMLStreamReader it wraps) can keep native parser buffers alive well past when an application logically considers a message "done," and for MTOM messages specifically, unclosed Attachments objects can leave temporary files backing large binary parts sitting on disk instead of being cleaned up.

1. Audit code paths that navigate only part of a tree - via serializeAndConsume(), an early return, or a caught exception - to confirm the builder's close() is still reliably called even when the "happy path" full traversal doesn't happen.
2. Check for MTOM-specific temp file buildup: Axiom's Attachments handling for MTOM messages can spill large parts to disk, and those temp files need cleanup tied to the message's lifecycle finishing, not just to garbage collection of the Java objects.
3. Wrap parsing/consumption logic in a pattern that guarantees cleanup regardless of the exit path - a try/finally block calling builder.close(), mirroring how you'd handle any other closeable resource - rather than relying on cleanup only in the normal, expected flow.
4. Under load testing, monitor both JVM heap and the process's open file descriptors/temp directory size together, since a builder-related leak here often shows up as file-handle or disk-space growth even when heap usage looks superficially stable.

The underlying theme is that Axiom's builders are stateful resources tied to an underlying stream (and sometimes disk-backed attachments), not disposable value objects - the same discipline you'd apply to closing a JDBC connection or a file handle applies here, and it's easy to miss specifically because a "read-only" navigation call doesn't look, at the call site, like something that needs a matching cleanup step.