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
