I'm PHP dev transitioning to Java, but I had quite same issue when nginx
gzipped output of my application which was already gzipped.
On 2014.12.10. 15:37, Ben Summers wrote:
Hello,
I'm chasing a bit of a strange bug. I'm wondering if anyone can suggest how I
should go about generating a reproducible test case.
I've got one particular response which is almost entirely sent, then there's a
delay of approx 30 seconds, then the final bit arrives and the page rendering
is completed. It happens the same in Firefox, Chrome and Safari.
It's from an embedded Jetty 9.2.5 returning a web page which is 438368 bytes
uncompressed, 71418 bytes compressed, with about 262 bytes of headers, over an
SSL connection.
The gzipping is done by our app, not jetty. It's sent by calling
servletResponse.getOutputStream() then write() on the stream via a
GZIPOutputStream with an 8k buffer.
I'm almost certain the write() returns quickly, and as far as the app is
concerned, it finished handling the request in a few milliseconds.
It's pretty much 100% repeatable.
Reverting to 9.2.3 solves the problem.
I'm running on a Solaris derivative:
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) Server VM (build 24.71-b01, mixed mode)
I can't seem to reproduce this outside our production environment with data I
can't share. I've tried generating all sorts of responses of about this size,
and even using the text of the offending response, all to no avail.
Any suggestions welcomed!
Thanks,
Ben
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
