Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
High response time in the GZipResponseFilter deployed to Tomcat 8 / JDK 8 #65
I'm updating my app to deploy on Tomcat 8, consequently JDK 8.
The response time is OK when I use the Tomcat 7, JDK 6 and GZipResponseFilter
Can you check this issue?
I'm unable to reproduce it with Tomcat 8.0.14 (downloaded and unzipped as is; so I didn't touch any config file), JDK 1.8.0_20, Mojarra 2.2.7. I just created a simple test page with a bunch of random PrimeFaces 5.0 components such as p:schedule, p:calendar, p:layout which all require quite some CSS/JS files. All of them were properly downloaded without "hanging".
A list of exact versions and a reproducer WAR would be very helpful to nail down this problem.
This issue is very weird.
When the GzipResponseFilter is disabled, the "Receiving" step finishes the download and then finishes the step correctly in 3.4ms.
But when I enable the GzipResponseFilter the "Receiving" finishes the file download, but don't finishes the step. It takes 20 seconds to finish the step.
This issue looks like a resource locking / blocking inside the http response.
Just for mention, this issue doesn't occur when I enable the GZip compression direct on the Tomcat configuration.
Finally, I got a minimal reproducer app.
This is my environment:
When I access the http://localhost:8080/gziptest/index.css I see the high response time.
Can you reproduce the issue on your environment?
Reproduced and nailed down: there's a "Content-Length" header on the response which didn't belong there. It turns out that Servlet 3.1 introduced a new setContentLengthLong() method allowing to set a long instead of int as content length. Tomcat's DefaultServlet used this, but the GzipHttpServletResponse didn't take this into account. This has been fixed. I will bake snapshots later.
added a commit
Oct 30, 2014
FYI: I couldn't reproduce it because the CSS file was being served as a plain vanilla webapp resource by Tomcat's builtin DefaultServlet instead of as a true JSF resource via a /javax.faces.resource URL as generated by <h:outputStylesheet>. I didn't expect one would do that in a JSF webapp :)