On 09.09.2009 16:11, balakarthik.baska...@wipro.com wrote: > Thanks for your reply.I am able to simulate the problem with 1.2.28 as > well.This is the mod_jk version that I used in my local setup.Our prod > version has 1.2.27.So regardless of the version,the issue is seen.
OK > Pfa the detailed debug logs of mod_jk for different combinations that I > tried out and when the issue occured. Thanks. The reason is in your configuration. There is one switch that is much recommended and form the logs it seems you already found and tried it: the recovery_options. See: http://tomcat.apache.org/connectors-doc/reference/workers.html and also look carefully at: http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html You should set recovery_options to 7. This switch is exactly for disabling request retries in case Tomcat already replied, or at least the request was send to Tomcat. It should fix your problem. So maybe we are back to the beginning: why don't you post your config, so we can see, if there is more potential for optimization. >From the timestamps in the jk log I can see e.g., that you are using a hard configured time stamp format. That's not to good, because that way you don't see the milliseconds, that are logged since a couple of versions by default. > The other main scenario apart from the one explained below that I am > seeing is when I tried setting up a JBOSS cluster node setup of two > nodes with session replication (with socket_timeout not set or default > to infinite).Node 1 app code is made to take a longer time to > respond.When the node1 has started writing a huge chunk,I abruptly kill > the node 1 and I see mod_jk failing over the request to node2.But the > end result is the data written by node1 until it has been killed clubbed > with the data written by node2 is seen in the browser. Will also be fixed by recovery_options. > This is where we are not able to make a decision of even having > socket_timeout to be infinite or to a defined limit(as we never know how > long/when the root cause of the delay might occur) as there may be lot > of possibility of failover and we suscpect the multiple content issue > would be coming up when failover happens.The worst part is when akamai > comes into picture where I hope this partial content is cached in their > edge servers and completely messes up by showing the content to the > users.So for all other subsequent requests,the data which is served from > akamai cache is the messedup multiple content thereby completely > degrading the customer experience. See above. I generally am not in favor of the socket_timeout. Even after your original problem goes away by using recovery_options, the behaviour of the general socket_timeout is not very nice. I would stick with a couple of the other timeouts. Regards, Rainer > -----Original Message----- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Wednesday, September 09, 2009 7:16 PM > To: Tomcat Users List > Subject: Re: Need Help - Mod_jk/Apache - Mutiple Content issue > > Hi, > > On 09.09.2009 06:56, balakarthik.baska...@wipro.com wrote: >> Hi, >> In our production envt,we are making use of a configuration of >> Apache(2.2.10-1)+Mod_jk(1.2.27)+JBOSS(4.0.5)+ATG 2007.1. >> >> We are facing a problem where multiple content is being displayed to >> the customer.It was observed that the pages were being periodically >> rendered or rendered multiple times.The page was rendered with a >> standard navigational header showing two times. Depending on the >> browser, the duplicate headers was stacked vertically or horizontally. > >> The issue was further exasperated because a particular fragment was >> cached at Akamai, and once this double header was served up by origin, > >> it was then cached at Akamai and included in customer pages at a very > high rate. >> >> Our Analysis So far >> >> We did a local setup of the above configuration and we are able to >> recreate the multiple content problem.The setup involves apache >> configured with mod_jk having two worker nodes balanced by a load >> balancer worker.The problem occurs when the app code takes a longer >> time than the time defined in the socket_timeout parameter of the >> worker nodes. We have set the socket_timeout config of the worker >> nodes to be 2 secs for both nodes and the appserver jsp logic is made >> to sleep for 3secs. >> >> The behaviour observed is as follows: >> >> The first worker node fails after the socket timeout time and the >> second worker node is able to retreive the response from the app >> server.However while turning on the debug of mod_jk,we are observing >> that a partial content has been served by the AJP Connector/Container >> from the App server for the node 1.Also,a full content has been served > >> for the request initiated by node2.The full content follows the >> partial content that has been already sent to the client .Hence the >> browser has a duplicate/multiple content shown to the customers. >> >> What are we looking for? >> >> The open question at this point that we have is how/what configuration > >> could either limit this partial response (or) send an error response >> to the client when the worker node is found to be inactive? (or) >> handling the situation of the app server taking a longer time to >> respond than the defined timeouts (in mod_jk) and a partial content >> being writtent into the socket,received by mod_jk and sent to the > client? >> >> The problem gets aggravated when we akamai comes into picture. > > Thanks a lot for your very careful analysis. I usually do not recommend > socket_timeout, so that's why I never noticed such behaviour. But of > course this is a bug which has to be fixed. > > Is there a possibility of getting a hand on the part of the debug log, > where the problem occurs? I'm pretty sure, we can quickly fix it then. > > If the problem is easy for you to reproduce, would you mind testing once > again using version 1.2.28 of mod_jk? There have been some changes there > not directly related to the problem, but it would be good to know, > whether you can still reproduce with 1.2.28. I will nevertheless > investiaget, what's wrong in 1.2.27 and possibly also 1.2.28. > > Thanks again and a debug log snippet would be very helpful. > > Regards, > > Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
