Fix native memory leak in GzipHandler

[denvned]

Looks like this leak shows itself only with asynchronous responses.

Some relevant info: http://www.devguli.com/blog/eng/java-deflater-and-outofmemoryerror/

[WalkerWatch]

@denvned Before we can accept this Pull Request, you will need to sign an Eclipse Contributor Agreement. This is a requirement of the Eclipse foundation and is mandatory. It is very easy to set up, and instructions can be found here.

[joakime]

Calling .reset() and .end() on the Java Deflater does not fix the memory leak.

See Issue #293 along with the JVM bugs

• http://bugs.java.com/view_bug.do?bug_id=4797189
• http://bugs.java.com/view_bug.do?bug_id=6293787

There are plans to add a Deflater/Inflater pool to get around this issue (See Issue #300), so that GzipHandler, Jetty Client, and WebSocket's Permessage-Deflate all benefit from the reusing Deflater/Inflater objects, and minimize the memory leak effect.

[denvned]

Calling .reset() and .end() on the Java Deflater does not fix the memory leak.

@joakime But the issues on bugs.java.com you linked says that calling the end() on Deflater solves memory leak problem. What did I miss?

[joakime]

We've been down this path before, several testcases on multiple Deflater use alone have shown the bug is still present, even if using .end().

This is not a big problem for most Java applications, that only use 1 Deflater over their lifetime, but Jetty can use 1 for each HTTP/1.1 connection, and multiple for each WebSocket connection (that uses permessage-deflate) extension, potentially 10's of thousands of Deflater/Inflater instances, when it only needs a few hundred and reuse them.

[joakime]

I'm not trying to get you to change this PR, its still useful, as its right thing to do for a Deflater.
Just don't expect to to have much of an impact on the Deflater memory leak.

[denvned]

We've been down this path before, several testcases on multiple Deflater use alone have shown the bug is still present, even if using .end().

@joakime Are you saying that calling Deflater#end() does not actually free the off-heap memory natively allocated by Deflater? Have you reported it on http://bugs.java.com/?

[denvned]

Signed ECA.

[gregw]

Thanks!
But we should get a hurry on for #300 as well. @denvned a PR for that would be welcome as well :)

[gregw]

Note that the GzipHandler is already using a Threadlocal "pool" of deflators

[gregw]

Just to clarify the discussion here. The GzipHandler is already recycling Deflaters and this PR just improved the handling by calling reset() if the Deflater is recycled and end() if it isn't.

However #300 still applies to Websocket and it could use a similar strategy.