mayurbm commented on PR #25555:
URL: https://github.com/apache/camel/pull/25555#issuecomment-5351811667

   ## Priority Justification
   
   This is not just a cosmetic exception-message improvement. The impact under 
real production load is significantly worse than it appears:
   
   ### Why this deserves high priority
   
   **1. Expensive DOM construction before failure**
   
   Invalid / non-XML content does not just produce a clean exception — it 
forces expensive DOM construction first. The JDK XML parser allocates internal 
buffers, parser state, and partial DOM nodes before it reaches the prolog and 
throws. Every failed conversion has already consumed heap memory proportional 
to the payload size.
   
   **2. Retries multiply the cost**
   
   Retries multiply the cost because the same stream objects are rebuilt on 
every attempt. A single bad payload hitting a retry-enabled route or a CXF 
fault path can trigger 3–5 full parse attempts, each allocating and immediately 
abandoning the same DOM scaffolding.
   
   **3. Heap and GC pressure under load**
   
   Under load or with large bad payloads this becomes a significant heap-memory 
and GC problem, even though the final outcome is always a parse failure. In 
high-throughput CXF/SOAP services receiving occasional non-XML error responses 
(upstream 5xx HTML pages, JSON fault bodies), this pattern can saturate the 
old-gen heap and trigger full GC pauses or OutOfMemoryError — all for payloads 
that were never going to parse successfully.
   
   ---
   
   ### Mitigation (until this fix is merged)
   
   Perform a cheap prefix + size check on the raw  /  before any type 
conversion or CXF binding runs. This rejects the payload early and avoids the 
DOM allocation entirely:
   
   
   
   The fix in this PR moves exactly this check into  itself, making it 
automatic for all routes without requiring any application-level workaround.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to