Many thanks for pointing me to the patch.
At first glance, it appeared that this was the same workaround as that
in Sun/Oracle's bug comments. It is clearly *based* on the same
workaround, but it contains tweaks that avoid the extra null byte
issue. There are no comments to this effect, but the Tomcat patch is
clearly more robust than that in the Sun/Oracle bug comments.
--
Jess Holle
On 4/26/2010 7:51 PM, James Ward wrote:
I just ran into this a few weeks ago. Here is the associated Tomcat bug with a
patch:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48738
-James
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Jess Holle
Sent: Monday, April 26, 2010 6:12 PM
To: [email protected]
Subject: [The Java Posse] Forcing gzip flush in Java
Sun/Oracle Java has a longstanding, silly, but horrific bug (yes, not
just one, but that's another story).
The bug I'm talking about is
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4813885 and in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4255743 -- 2 reports,
but really just one bug.
The issue here is that a real flush() is really necessary for a lot of
use cases, but applying the workaround noted:
def.setInput(EMPTYBYTEARRAY, 0, 0);
def.setLevel(Deflater.NO_COMPRESSION);
deflate();
def.setLevel(Deflater.DEFAULT_COMPRESSION);
deflate();
out.flush();
does not actually work in all cases. If this is done after all bytes
have been sent to the stream (even before finish() is called), in very
rare cases an extra null byte will appear in the (uncompressed) output.
Does anyone have a solution for this (without resorting to a 3rd-party
library)?
--
Jess Holle
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
