On 24 Nov 2010, at 18:07, declan harrison <harrison.dec...@gmail.com> wrote:
> Hi > > This is my first post to tomcat user mailing list. Hello. > I'm using Tomcat 6.0.24 on Linux RHELS release 5.3 (Tikanga) on a 64 bit OS. Which JVM version? > I have deployed a Web application within Tomcat. The Web App in the > main sends dynamically created video content to a client over the > HTTP1.1 Blocking Connector. How are you writing to the output of the response? > I have configured Tomcat to use the Blocking IO HTTP Connector. Main > Configuration parameters are the following maxThreads="1000" > minSpareThreads="300" > > The use case is the following. HTTP Client uses HTTP Post to send > video content to a Web App in Tomcat. Tomcat Web App Dynamically > re-codes this video content and sends this video payload in the body > of the HTTP Response (response to HTTP Post) to the client. > > As the Web App doesn't know the final size of the video content it > sends so it does not add the HTTP "Content-Length" header in the > HttpServletResponse. The Tomcat HTTP Connector (I presume) correctly > knows to send this content as a HTTP Chunked response, i.e. > Transfer-Encoding: Chunked". > > So this work well nearly all of the time, i.e. correct headers are > sent and all the data is sent as chunked response. However when I am > putting a load through the system e.g 40 or 50 concurrent threads > processing content and I make another single HTTP request to the Web > App that is normally rejected with a 500. What us the cause, and is there an exception stacktrace in the logs? > However before the Tomcat > thread finalizes it response to this specific request I terminate the > client and its request (ctrl-c), then the next time this same Tomcat > thread is re-used it will send the video in the HTTP response body as > Un-Chunked and not Chunked as expected but the HTTP status code is 200 How are you determining that it is the same thread? > as expected. Also the "Content-Length" header is missing on this > response and all the other HTTP headers that the Web App inserted are > not sent. This then causes problems for the HTTP Client requesting > said content. > > However the next time after this that we re-use this thread (3rd time > used) then its back to working normally again sending HTTP Chunked > response as exepcted. That sounds like the thread is only being reset properly after it's been used a second time. > So the normal response is like this. Note chunked response and chunk > size is "2000" hex about 8K. > > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > x-my-session-id: 1000128946853721720696116 > Content-Type: video/x-flv > Transfer-Encoding: chunked > Date: Thu, 11 Nov 2010 09:42:17 GMT > > 2000 > onMetaData > totalduration > canseekontime > bytelength > > The problems response looks this this. Note no Content-length header > or Chunked response. > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Date: Wed, 10 Nov 2010 14:32:25 GMT > Connection: close > > FLV............... > > To replicate this issue is very much dependant on when I terminate the > client request. If I terminate too late or too early I dont see this > issue. It some sort of race condition. Do you still see a 500 when you terminate, if so is it the same stacktrace? Do you have any part of the response stored as an instance field in your servlet? p > I upgraded to Tomcat 6.0.29 as I had seen some security issues > relating to Transfer-Encodings, here > http://tomcat.apache.org/security-6.html. However it didnt make any > difference. > > I have also read the bug list and cannot see this same issue. > > Any ideas what the issue is here and is there anything I can do to mitigate > it? > > Thanks > Declan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
