This technote describes an issue with the FusionReactor Compressor when used with Tomcat.
With FusionReactor > Compression Settings > Compression Support > GZIP Response set to Enabled, you may see resource delivery stall for up to 20s.
This occurs only in static content, whose length can be definitively known in advance, such as .gif, .jpg, .html and .css files.
When delivering a file, the Content-Length header is set by Tomcat to be the original (uncompressed) size of the file, regardless of whether the content is being compressed or not.
The effect of this is that the compressor finishes delivering the content much sooner than the browser expects. Tomcat then keeps the connection open for up to 20s (this value may change based on your local configuration and Tomcat version) in Keepalive mode, in case any more content can be pipelined without reopening the connection.
When Tomcat closes the connection after 20s, the browser assumes the received size is the actual content length, and processes it.
The last workaround, introduced in 5.2.0 and later, causes FR to send a Content-Length of -1, requiring tomcat to compute the header itself.
Warning: If the compressed response does not fit within a single Tomcat buffer (in Tomcat 8, currently 8192 bytes), Tomcat will fall back to the old behaviour, calculating the Content-Length from the original file size, again causing a stall.
|Last Updated:||05/Aug/14 4:17 PM|
Comments are closed.