We've noticed unusual memory consumption pattern with one of our services based on Undertow. After a lengthy investigation with native memory profiling, the issue boiled down to the fact that we use gzip compression for output and GzipEncodingProvider respectively. Deflater releases memory either when end() function is called explicitly or when it's garbage-collected which is not particularly reliable. Our fix is to wrap existing gzip conduit into FinishableStreamSinkConduit and use deflater.end() as finish operation. I assume it would be a proper way for DeflatingStreamSinkConduit to handle this out of the box.
- clones
-
UNDERTOW-1112 Potential memory leak with DeflatingStreamSinkConduit
- Resolved
- is cloned by
-
JBEAP-11845 (7.0.z) UNDERTOW-1112 Potential memory leak with DeflatingStreamSinkConduit
- Closed