Tomcat 8 vs webtop

Another Friday challenge was a dumb slowness of webtop under tomcat 8 – 80 seconds to get login page:

compare with weblogic:

What is the problem? For some weird reason when webtop is running under tomcat 8 the size of returned content is not in sync with http headers:

i.e. server reports that content size is 20K but the real size is 4K, so browser gets confused:

bash-3.2$ curl -D /dev/stderr 'http://localhost:8080/webtop/wdk/include/locate.js' \
> -H 'Pragma: no-cache' -H 'Accept-Encoding: gzip, deflate, sdch'  \
> -H 'Connection: keep-alive' -H 'Cache-Control: no-cache' --compressed > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: max-age=86400
Accept-Ranges: bytes
ETag: W/"20735-1417517700000"
Last-Modified: Tue, 02 Dec 2014 10:55:00 GMT
Content-Encoding: gzip
Content-Type: application/javascript
Content-Length: 20735
Date: Sat, 26 Sep 2015 10:42:51 GMT

23 20735   23  4948    0     0    246      0  0:01:24  0:00:20  0:01:04     0
curl: (18) transfer closed with 15787 bytes remaining to read
bash-3.2$

Who is to blame now? I believe EMC thinks ASF broke something in new tomcat, but the real reason is EMC developers do not follow documentation, check example provided by ASF (webapps/examples/WEB-INF/classes/compressionFilters/CompressionResponseStream.java):

} else {
    response.addHeader("Content-Encoding", "gzip");
    response.setContentLength(-1);  // don't use any preset content-length as it will be wrong after gzipping
    response.setBufferSize(compressionBuffer);
    gzipstream = new GZIPOutputStream(output);
}

Indeed, when I put missing calls into com.documentum.web.servlet.ThresholdingDeflateOutputStream#startDeflating everything started working smoothly:

bash-3.2$ curl -D /dev/stderr 'http://localhost:8080/webtop/wdk/include/locate.js' \
> -H 'Pragma: no-cache' -H 'Accept-Encoding: gzip, deflate, sdch'  \
> -H 'Connection: keep-alive' -H 'Cache-Control: no-cache' --compressed > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: max-age=86400
Accept-Ranges: bytes
ETag: W/"20735-1417517700000"
Last-Modified: Tue, 02 Dec 2014 10:55:00 GMT
Content-Encoding: gzip
Content-Type: application/javascript
Transfer-Encoding: chunked
Date: Sat, 26 Sep 2015 11:09:14 GMT

100  4948    0  4948    0     0   362k      0 --:--:-- --:--:-- --:--:--  371k

4 thoughts on “Tomcat 8 vs webtop

  1. I’m using webtop 6.8 + java 1.8 u40 + tomcat 8.0.23 and I haven’t had that behaviour, it takes about 200/400ms to get the login page with/without cache

    Like

  2. yes, it’s noticeably slow without that parameter (and that parameter is stated in the documentation btw, for once EMC did put everything on the docs). But I haven’t had the need to decompile/modify emc’s classes (and i’m not saying that disabling wdk compression is the right solution)

    Like

  3. So, what is the question? You blindly follow wrong, misleading and obsolete documentation – it is your choice. I do think that web application must be application server-agnostic, If it is not it is a bad application which further will cause a lot of pain.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s