Just FYI to those that were following this thread, this was a Cocoon (2.1.5) issue that caused this, not Tomcat.
Turns out that the Cocoon 2.1.5 ResourceReader sets some response headers willy nilly. If you have another component that uses a resolver to access a pipeline that uses the reader (eg. using the cocoon: pseudo protocol, in our case it was a custom PDF concatenation serializer that called out to a sub-pipeline to get a separator page pdf), then the reader sets the Content-Length http reponse header in the original response object. If the originating component/pipeline generates output that is longer than what the reader grabbed, then it gets truncated. Not sure why Cocoon doesn't create a new response object when you try to resolve a local "cocoon:/" resource, but it doesn't. Creating a customized ResourceReader with all response header setting commented out resolved the issue for me. ....Andrzej > I have a situation where some requests that get sent to Tomcat are very long > running (basically batch operations). I've been testing with a request that > takes just over 7 minutes to process and returns and XML document as a > response. > > The problem I'm having is that the response gets truncated. It's always > truncated at a consistent spot. It always sends back exactly 3207 characters > in the response body and this is consistent using Firefox or a commons- > httpClient based script. > > Shorter running requests don't truncate anything, regardless of how long the > response might be. > > I'm running Tomcat 5.0.28 and my Connector in the Tomcat server.xml file looks > like: > > <Connector port="80" > maxThreads="150" > minSpareThreads="25" > maxSpareThreads="75" > enableLookups="false" > redirectPort="8443" > acceptCount="100" > debug="0" > disableUploadTimeout="true" > tcpNoDelay="true" > connectionLinger="-1" > connectionTimeout="6000000" > connectionUploadTimeout="6000000" > keepAlive="true" > maxKeepAliveRequests="-1" > serverSocketTimeout="0"/> > > I've tried all sorts of timeout values in the above....including zero values, > but the behaviour is consistent. Long running invocations truncate the > response body to 3207 characters. I've also tried changing the client side > timeout values, but again, to no avail. > > I'm kinda stumped as to what might cause this, especially given the very > consistent response body length that is always returned. Almost seems like > some strange buffering issue that is timer-related. > > Any ideas? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
