On 15.09.2009 14:50, balakarthik.baska...@wipro.com wrote: > I tried with all the configuration that you defined and am still able to > simulate the partial content when I make the code to sleep for a time > greater than the time defined in the reply timeout.
Yes, that's expected when using a reply_timeout. > I understand that once the partail content is written into the client > pipe,it would not be feasible to get it back or ignore it.We are working > on finding the root cause of what is creating a delay in th app side of > more than 3 mins of reply timeout defined in prod. Try using thread dumps. > But just looking at a general case,considering a long running > transaction/idle thread in the app for a 1 in 1M probability,if the case > is going to occur,there will be definitely be a partial content seen.And > we are afraid this would be aggravated when akamai comes into play.We > did speak to akamai on this regard and they have a opinion that there > would be a performance hit when any patching is going to be applied at > their end. So they sacrifice correctness for performance. To bad. > So,do you think of any fall back approach or a way to eliminate this > situation from apache/mod_jk perspective (although the current > configuration does not help) (or) do u think/aware of any cases/clients > who uses mod_jk/apache where the situation would have been handled > better (or) even if everyone who uses mod_jk/apache would be failing > with the same issue when such a situation (app code taking a longer time > and leading to partial content sent) would be faced by them? 1) You can switch off the reply_timeout But then depending on how often those long running requests happen and how long they actually take, you might slowly loose thread after thread until finally all resources are exhausted. Furthermore other components, like Apache or some other component in front might still interrupt request processing. 2) You could write a filter either in Apache or Tomcat to save alll response data until it is finished and only then send it to the client. This will be complex, error prone and will use a lot of memory ressources. 3) Fix your application Use thread dumps to find out what is happening. If you add %D to the access log, you can find out, what kind of URLs are responsible for the long running requests. You can then use a feature mod_jk allows in version 1.2.28, namely making the reply_timeout depending on the URL. Since you are already using a long timeout (e.g. 300 seconds), you might also need to globally adjust "Timeout" in Apache. For the URL specific reply_timeout ses http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Rule%20extensions I would put all efforts in fixing the app. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
