High response time in the GZipResponseFilter deployed to Tomcat 8 / JDK 8 #65

Closed
gusehr opened this Issue Oct 7, 2014 · 12 comments

Projects

None yet

2 participants

@gusehr
gusehr commented Oct 7, 2014

Hi there!

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.

@BalusC
Member
BalusC commented Oct 9, 2014

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.

@gusehr
gusehr commented Oct 9, 2014

OK!
I will work on a reproducer WAR.

Thanks.

@gusehr
gusehr commented Oct 16, 2014

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.

See ya.

@gusehr
gusehr commented Oct 22, 2014

Hi there!

This issue is very weird.
The request to a regular CSS file executes these steps:

6ms Blocking
6ms DNS Lookup
0.9ms Connecting
1ms Sending
24ms Waiting
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.

Thank you.

@gusehr
gusehr commented Oct 22, 2014

Finally, I got a minimal reproducer app.
I sent it to your gmail.

This is my environment:
Windows 7 64bit
jdk1.8.0_20
JSF 2.1.27
Omnifaces 1.8.1
Tomcat 8.0.14
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.

@BalusC BalusC added a commit that closed this issue Oct 30, 2014
@BalusC BalusC Fixed #65: Intercept on new Servlet 3.1
HttpServletResponse#setContentLengthLong() as well.
ae7838e
@BalusC BalusC closed this in ae7838e Oct 30, 2014
@BalusC
Member
BalusC commented Oct 30, 2014

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.

@BalusC BalusC added a commit that referenced this issue Oct 30, 2014
@BalusC BalusC Fixed #65: Intercept on new Servlet 3.1
HttpServletResponse#setContentLengthLong() as well.
64f8668
@BalusC
Member
BalusC commented Oct 30, 2014

New 2.0 and 1.10 snapshots with the fix have been baked. Can you please give it a try?

@BalusC
Member
BalusC commented 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 :)

@gusehr
gusehr commented Oct 30, 2014

Hello Bauke.
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?

Thank you.

@BalusC
Member
BalusC commented Oct 30, 2014

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.

@gusehr
gusehr commented Oct 30, 2014

OK!

I tested the 1.10 snapshot and it is OK!
Thank you!

@BalusC
Member
BalusC commented Oct 30, 2014

Thank you for reporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment