HI All, The problem is solved now . we are have implemented a callback functionality where after every 45 seconds we call back the same method again .Hence making sure that there is no timeout.
But as per identifying the actual reason behind the problem i tried to reproduce the issue,after every time after response exceeds 1 min i would get same internal error with same logs as I had mentioned earlier .I got the confirmation that there is firewall between users browser and web-server but i could not get more information about firewall . I have read many blogs where people have faced same issue because of firewall. I had no clue that firewall would drop the connection if it does not recieve response within stiplulated time. Can i increase this timeout period ? if firewall was not there then my app would i worked properly ? On Mon, Mar 31, 2014 at 8:29 PM, Mark Eggers <its_toas...@yahoo.com> wrote: > On 3/31/2014 4:18 AM, Vicky B wrote: > >> there is a firewall between browser and apache httpd and i am not sure if >> there is a firewall between apache and tomcat (mostly no). >> > > Mostly? Mostly? As in sometimes there's a firewall, and other times > there's not, but mostly not? > > Or do you mean that you're supporting this application at multiple sites, > and it's misbehaving at some sites? And that most of the sites do not have > a firewall between Apache HTTPD and Apache Tomcat, but some do? > > Or do you mean that you're almost certain that there is no firewall > between Apache HTTPD and Apache Tomcat, but you're not 100% certain? > > > But why would this firewall drop the connection ? >> >> > Firewalls can be configured to drop connections after a certain amount of > inactivity. If you have a long-running process and are not sending > information back to the user, there are many places where the connection > could be closed. > > 1. Between Apache Tomcat and Apache HTTPD > > As I mentioned earlier, if you have configured an AJP timeout (which is > not the default configuration) and it is too short, Apache HTTPD will close > the connection and send an error message back to the browser. > > 2. Firewall between Apache Tomcat and Apache HTTPD > > A firewall can be configured to close connections after a period of > inactivity. > > 3. Firewall between Apache HTTPD and the browser > > A firewall can be configured to close connections after a period of > inactivity. This might generate the type of error in the log extract that > you posted earlier. > > However, that error may be completely unrelated to the problem, as well as > all of these other musings many of us are doing. > > The short answer is that none of us know, because you have not provided > enough information for us to be anything more than speculative. > > If you want help in resolving this problem, you need to provide us with > answers to the questions we've asked (as a start). We can then help (mostly > by asking more questions) narrow down the possibilities, and then possibly > help you solve the problem. > > Or as André politely pointed out, give you enough information so that you > can go back to the developers so that they can fix the problem. As he has > pointed out, 90% of the time it's an application issue. > > There is no 'magic' one line answer and configuration that will fix your > problem (most likely - but again, we don't know). > > If you do not have the answers to the questions we are asking, please go > ask someone who does have the answers and the access for the information. > > Otherwise we're all just wasting time and bandwidth. Meanwhile your users > are still getting errors . . . > > . . . just my (not caffeinated) two cents > /mde/ > > PS - please, please, please do not top-post. Your comments when they're > read first make no sense until you scroll to the bottom and read the rest > of the message. > > /mde/ > > > >> On Mon, Mar 31, 2014 at 3:16 PM, Howard W. Smith, Jr. < >> smithh032...@gmail.com> wrote: >> >> On Mar 31, 2014 3:48 AM, "André Warnier" <a...@ice-sa.com> wrote: >>> >>>> >>>> Howard W. Smith, Jr. wrote: >>>> >>>>> >>>>> On Sun, Mar 30, 2014 at 9:54 PM, Caldarale, Charles R < >>>>> chuck.caldar...@unisys.com> wrote: >>>>> >>>>> From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] >>>>>>> Subject: Re: timeout >>>>>>> >>>>>>>> >>>>>>>> - and if that is not the reason, then find the person responsible >>>>>>>> for >>>>>>>> >>>>>>> >>>>>> the >>>>>> >>>>>>> >>>>>>>> in-between equipment and ask them why their junk closes the >>>>>>>> >>>>>>> connection >>> >>>> before your application has a chance to respond >>>>>>>> >>>>>>> >>>>>>> 'junk'? please clarify the usage of the word 'junk', here. :) >>>>>>> >>>>>> >>>>>> I think the definition "something of poor quality" would fit in this >>>>>> >>>>> case, >>> >>>> if the poor quality were a result of configuring equipment without >>>>>> >>>>> regard >>> >>>> to the requirements of the network users. >>>>>> >>>>>> - Chuck >>>>>> >>>>>> >>>>> understood, thanks Chuck. :) >>>>> >>>>> >>>> Yes, what I meant precisely was thus : if after receiving numerous >>>> >>> complaints from your users and your boss that your application is >>> misbehaving; after an in-depth review of the Apache httpd and tomcat >>> on-line documentation; after a level-headed discussion of the issue with >>> a >>> group of independent experts; after a thorough witnessed interview of a >>> significant sample of the users to ascertain their professional behaviour >>> in front of a browser and the absence of any problem with their mouse >>> buttons; after a careful and time-consuming examination of all the >>> evidence, including the access logs of both tomcat and httpd; if after >>> all >>> that thus you would come to the inescapable conclusion that it is the >>> intermediate firewall/gateway that is the cause of all the trouble, then >>> when you talk to the people responsible for that equipment, the word that >>> might come to mind then, to qualify this equipment and its settings seen >>> as >>> a whole, is "junk". >>> >>>> >>>> Thank you for offering me the opportunity to clarify this section of my >>>> >>> previous post. >>> >>>> >>>> >>> You're welcome, the pleasure was [almost] all mine, and thank you for the >>> clarification. :-) >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *Thanks & Regards Vickyb*
