Hi Rainer, The other possible configuration that I think probably we might be lacking/quite different is that we are loadbalancing the requests among 240 worker nodes each pointing to one app instance (all app instances available in the default cluster) and we use Busyness algorithm(for load balancer worker).
We have seen partial content from the middle of the pages as well which was quite difficult to simulate in my local setup. Do you think load balancing among 240 workers could be a possibiltiy of messing up with request responses/adding up delay when there is a failover/other load balancing situations? (Or) is there a defined limit of worker nodes to be balanced that have been identified/defined? Regards, Bala -----Original Message----- From: Balakarthik Baskaran (WT01 - Retail, CPG, Transportation & Gover Sent: Tuesday, September 15, 2009 6:20 PM To: 'Tomcat Users List' Subject: RE: Need Help - Mod_jk/Apache - Mutiple Content issue Hi Rainer, 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. 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. 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,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? Thanks again for you help. Regards, Bala -----Original Message----- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Monday, September 14, 2009 4:29 PM To: Tomcat Users List Subject: Re: Need Help - Mod_jk/Apache - Mutiple Content issue On 14.09.2009 12:02, balakarthik.baska...@wipro.com wrote: > But I think you mentioned earlier that you were able to simulate the > problem. I didn't simulate, I understodd from reading the code. I also said, it should go away when using recovery_options. So please: - optimize your configuration - see whether you still have problems and let us know if so The configurations will not help with Akamai eventually caching incomplete responses. If a backend doesn't send the full response, we can't fix it with configuration. Regards, Rainer > -----Original Message----- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Monday, September 14, 2009 3:11 PM > To: Tomcat Users List > Subject: Re: Need Help - Mod_jk/Apache - Mutiple Content issue > > On 14.09.2009 11:33, balakarthik.baska...@wipro.com wrote: >> Thanks Rainer. >> Just Curious,did these settings helped to overcome the multiple >> content problem in your local setup? > > I never had a multiple content problem - maybe due to good > configuration. > >> Also,thanks for your pointer on the thread id's for getting the >> correlations. > > Regards, > > Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
