The use of @GZIP on input and output entities can lead to a sudden increase in off-heap memory usage due to the native code pointers being used by the Deflater and Inflater classes; these classes are used by the GZIPEncodingInterceptor and GZIPDecodingInterceptor via the GZIPOutputStream and GZIPInputStream respectively

Normally, the native code pointers are cleared when either closing the streams or when garbage collecting the no longer used objects (via the finalize() methods), but RESTEasy is not closing the used GZIP

{In,Out}putStreams since that would cause a premature closing of the underlying {In,Out}

putStream so it's relying on the finalize() methods and that is inherently unsafe.

I found out the hard way, because our server with 7.5G was configured with 5G heap for java and sustained a load of about ~200 gzipped requests coming in per second, all with gzipped responses; since I keep a lot in memory, after about 24K requests had come in, I see the heap usage at about 1.5G, but the resident memory usage grew in steps to almost 7.5G after which the OS decided to kill the java process

I created a patch (which I'll try to include in this bugreport) which explicitly ends the

{In,De}

flation after RESTEasy is done with the GZIP

{In,Out}

putStream and ran the code again and now the resident memory size nicely stays about 200mb bigger than the heap usage, which seems to be normal.