On Wed, Nov 24, 2010 at 7:32 PM, Pid * <p...@pidster.com> wrote: > 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. Hi there > >> I'm using Tomcat 6.0.24 on Linux RHELS release 5.3 (Tikanga) on a 64 bit OS. > > Which JVM version?
java version "1.6.0_18" Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode) > >> 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? > Im wrapping the response ServletOutputStream in a BufferedOutputStream; Something like this bufOutStream = new BufferedOutputStream(response.getOutputStream(),20480); >> 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? It is expected for my Web App to reject this request with HTTP status code 500. The input request content is invalid. So typically the Web App will log the problem with the input content and then call response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR ); I dont have an error code setup in the web.xml file. After having setup some HTTP response headers and then return from the doPost method. There is no exception backtrace as such, logged by tomcat as far as I can see. do you think that Tomcat itself is logging a stacktrace somewhere. Theres nothing in my log file apart from the expected warning/error message that the Web App log explicitly. > >> 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? So in my Web App log file i log the client IP address and Port. So for the client request which I terminate manually I perform this from a different IP address than the one were all the other requests are made from. The log file also logs the ThreadId of each log event e.g. Nov 22 17:54:19 hostname [ProcessName][1001][26348][tomcat-exec-243] INFO Bla Bla... Here you can see "tomcat-exec-243" is the thread Id. So then the next time a log event is performed that matches this threadId I see that it fails. > >> 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. > Yes that correct. It appears to me that the state of the output stream in the thread is all setup to send a non chunked response as it would with the 500 error it didnt send and so sends the video response non chunked and its only after that does it resset its state. Does each thread maintain state between different HTTP requests. I also tried increasing linger time on each socket. So I tried 5 seconds and right enough it took 5 or more seconds before Tomcat re-used this thread but the bad result was the same. >> 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? I dont get a stack trace theres no unexpected error and the 500 status isnt actually returned to the client because I have terminated the request before response sent by Web App. Im not sure where in the Tomcat code we are when the request is tore down. > > Do you have any part of the response stored as an instance field in > your servlet? Yes I have a reference to the HttpServletResponse, response.getOutputStream(), which I close when Im done. > > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
