I'm updating my app to deploy on Tomcat 8, consequently JDK 8.
I use the GZipResponseFilter to compress static files like css and js.
I saw that the GZipResponseFilter is hanging to download my static files (about 20s o.O) after deployed to the new Tomcat version.
The response time is OK when I use the Tomcat 7, JDK 6 and GZipResponseFilter
The response time is OK when I use the Tomcat 8, JDK 8 without the GZipResponseFilter.
Can you check this issue?
Thanks in advance.
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.
I will work on a reproducer WAR.
Just for mention, I'm still digging this issue.
I couldn't reproduce the problem in a simple app, but the problem still occurs in my application.
I will keep you informed.
This issue is very weird.
The request to a regular CSS file executes these steps:
6ms DNS Lookup
3.4 ms Receiving
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.
These 20 seconds is the connectionTimeout Tomcat connector config.
This issue looks like a resource locking / blocking inside the http response.
Do you have some clue or idea for investigation?
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.
I sent it to your gmail.
This is my environment:
Windows 7 64bit
Browser cache disabled
When I access the http://localhost:8080/gziptest/index.css I see the high response time.
Can you reproduce the issue on your environment?
Thanks in advance.
Fixed #65: Intercept on new Servlet 3.1
HttpServletResponse#setContentLengthLong() as well.
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.
New 2.0 and 1.10 snapshots with the fix have been baked. Can you please give it a try?
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 :)
I will download the snapshot then I will close the issue.
I do the deploy of my app to Tomcat 7, Tomcat 8 and Glassfish 3.
Do you see any compatibility problem with Omnifaces 1.10 on these environments?
OmniFaces 1.10 has still the same dependency requirements as previous 1.x releases, with the difference that it does NOT contain CDI targeted artifacts anymore.
I tested the 1.10 snapshot and it is OK!
Thank you for reporting!