You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sean Dawson <se...@gmail.com> on 2015/07/08 18:52:06 UTC

Content length, timeouts

Hello, we have a GWT 2.7 application that's deployed on tomcat7 (r57-63)
that uses RestyGwt to make REST calls to another server (which uses
RestEasy 3.11).

We're seeing several issues that seem to be clustered into two categories
(transferring binary data, exceptions with xml data) - with one overriding
theme (content length isn't correct - this is the application server
exception we see, and fiddler shows the same thing).

I'm trying to sort out all the pieces and was hoping I could get some
pointers in the right direction.

Locally when running super dev mode in IntelliJ, we cannot reproduce many
of the issues (the remaining ones seem to involve very low level debugging
of Response objects, etc).  With the binary data, it seems to revolve
around compression/gzipping, png's, and file sizes somehow.

But let me give you the more straightforward example/category...

- the GWT app on any current Windows7 browser makes a REST call to get some
xml data

     SerializableClass getData()

- partway through the generating of the data, the server throws an exception
- somewhere around 10-20 seconds later... (tomcat / the request times out?
and)... the client gets a failure result on the asynchronous call

We have a simple proxy that passes the call from the app server to the
secondary server so this may involve some issue there (and so I will try to
eliminate that part from the equation) - but the strange thing is that in
DEV mode, all parts are still in use but when the exception happens, the
client/browser gets notified immediately of the failure (this would be
using the jetty embedded server for GWT super dev mode instead of being
deployed on tomcat).

It seems that *someone* is setting the response header to expect 8000
bytes, but the server only generates 300 (maybe the length of the exception
message?) - and tomcat [or something related] (but not jetty) waits for the
rest to show up before failing.

Is there good info out there on content length handling in general, and how
that might vary by container, such as tomcat specifically?

Thank you.

Re: Content length, timeouts

Posted by Sean Dawson <se...@gmail.com>.
On Wed, Jul 8, 2015 at 12:52 PM, Sean Dawson <se...@gmail.com>
wrote:

>
> Hello, we have a GWT 2.7 application that's deployed on tomcat7 (r57-63)
> that uses RestyGwt to make REST calls to another server (which uses
> RestEasy 3.11).
>
> We're seeing several issues that seem to be clustered into two categories
> (transferring binary data, exceptions with xml data) - with one overriding
> theme (content length isn't correct - this is the application server
> exception we see, and fiddler shows the same thing).
>

Here's what I found out...

- RestEasy sets the Content-Length to the exception length when it gets
thrown
- If the proxy sends back less info (without changing CL),
tomcat/the-browser waits for a certain period and then times out / fails;
and fiddler complains about a mismatch CL
- if the proxy sends back MORE info (without changing CL),
tomcat/the-browser gets back the data sent *up to the limit of CL*; no one
complains
- if the proxy properly adjusts the CL, everything is fine

Does tomcat perform any semantic checks on the contents of outgoing HTTP
messages, e.g. (in our case) raising some kind of error/event if there is a
content-length mismatch?