On 10.09.2009 14:46, balakarthik.baska...@wipro.com wrote: > Hi Rainer, > > I did tried with a lot of combinations for the settings and can see that > when recovery_options is set,no multiple content is seen and partial > content is seen followed by an "OK" message when a huge chunk of data is > written. However,the failover case didn't at all work out when the > recovery_options is set.Pfa a doc with the scenarios that I tested and > the results that I am seeing. > > However,in our prod envt,we currently have the reply_timeout and the > recovery_options setting available and we have reomoved the > socket_timeout.The recent behaviour that we are observing is,unlike the > duplicate content with the header that we saw earlier with > socket_timeout,we are seeing some of the content in the middle of the > response being duplicated. > > We are making use of dynamic includes of the jsp files (with ATG dsp > tags) and when I tried having the same in my local setup,I could see the > response being written into the socket once the jsp completes.But not > able to replicate a scenario of recreating multiple content from the > middle of the page/content served by a fragment that is included. > > Pfa a file with the behaviour that I am noticing from the access and jk > log files.For the test app,I could see only one GET request and a > corresponding response in the jk log with the response time.I included > one image and I can see a corresponding entry for the image as well in > both files.However,there are no entries seen for the included jsp files. > > I am attaching the log entries from our prod envt as well which I took > when I was able to see a timeout reply in the jk file.However,from the > access log I couldn't interpret a corresponding entry/behaviour.Could > you pl help on how the multiple content could have been occuring in the > middle and your insights from the log files? (Also,pl note that we have > currenlty turned off akamai in prod and the timeout is seen without > akamai as well)
Let's start in the right way, first fix the configuration, then do and analyze the tests, maybe resulting in more config optimization. Please post your config. I had a quick look at the files you attached, but it looks very much like we first need to improve the config, before analyzing behaviour, that will likely not appear with the right config. > Also,reg your explanation about akamai,I can contact akamai to find out > if they can handle the prematurely closed data differently.Do you > remember any setting to the browser to interpret this invalid data based > on content length/premature closure?(just for testing though wouldn't > apply to real life scenario) No there is no such browser setting that I'm aware of. But akamai is not a browser, its a server that behaves more like a cache. So they need to solve a server problem, not an end user problem. They should immediately invalidate content, that was delivered over a connection that had a protocol abort. > Thanks much for your help.I can give you a call if you would like to > discuss this over phone. Lets first check the config, maybe then everything will be fine ;) Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
