[us...@httpd] mod_proxy_ajp | timeout | connection losts
Hi Apache2 professionals, we identified the following problem when using mod_proxy_ajp in combination with a balancer configuration (see detailed configuration below), that: - multiple HTTP requests seem to use the SAME AJP CHANNEL - when just ONE request is exceeding the configured ProxySet timeout configuration (see detailed config below), the following error is displayed within the central Apache2 error log (exact the time interval after the long running request): [Mon Nov 29 17:17:11 2010] [error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header - when this log entry occurs, all connections running over the above AJP channel are cut - including connections that do run much more shorter than the timeout interval specified. Possibly, Apache2 assumes the Apache Tomcat instance is not reachable anymore and switches from one to the other Tomcat server. - all clients running over this AJP-connection are lost and loose the connection to the server Here the long running request (duration is specified in microseconds): 10.35.32.123 - - [29/Nov/2010:17:12:11 +0100] POST /xxx/Dispatcher HTTP/1.1 500 538 request url Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR3.0.4506.2152; .NET CLR 3.5.30729) JSESSIONID=80AC6DFF149E802C3AA8735996CE7AA0.rb-wcmstc1; 80AC6DFF149E802C3AA8735996CE7AA0.rb-wcmstc1 - 300456752 Here, the following configuration - including the timeout interval: Proxy balancer://fs4server BalancerMember ajp://rb-wcmstc1.xx.x.xxx:8009 loadfactor=100 retry=10 route=rb-wcmstc1 BalancerMember ajp://rb-wcmstc2.xx.x.xxx:8009 loadfactor=100 retry=10 route=rb-wcmstc2 ProxySet stickysession=JSESSIONID|jsessionid ProxySet lbmethod=byrequests ProxySet scolonpathdelim=On #ProxySet nofailover=On ProxySet timeout=90 /Proxy When checking the documentation for mod_proxy, below http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass we identifed, there are TWO timeout settings available: - timeout - connectiontimeout Our questions: - how to prevent bundling HTTP-requests in JUST ONE AJP connection? - how to set timeout and connectiontimeout intervals to prevent connection losts? - are there any other possibilites to prevent that behavior? Any suggestions are very welcome! Best regards, Holger King Robert Bosch GmbH inside.WCMS (CI/AFP2) Postfach 30 02 20 70442 Stuttgart GERMANY www.bosch.comhttp://www.bosch.com Tel. 0711/811-59112 holger.k...@de.bosch.commailto:holger.k...@de.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Hermann Scholl; Geschäftsführung: Franz Fehrenbach, Siegfried Dais; Bernd Bohr, Rudolf Colm, Volkmar Denner, Wolfgang Malchow, Peter Marks, Peter Tyroller; Stefan Asenkerschbaumer, Uwe Raschke, Wolf-Henning Scheider
[us...@httpd] Connection Issues
Hi,
We're experiencing some odd behavior regarding connections taking a
long time to establish to our website. We've been running Apache in
production for over three years now and have recently began
experiencing issues where the server-status page, static, and dynamic
content response times will slow anywhere from a few seconds to long
enough for the connection to timeout.
Initially thinking we might be hitting some hard limits with the OS,
we've thoroughly audited our sysctl variables, tried disabling
iptables and conntrack, and ensured that we're not running out of
ephemeral ports or anything along those lines. Looking at netstat, it
seems we have a pretty large number of connections in TIME_WAIT which
is understandable since this is a high traffic website, but I'm
wondering if this value could indicate we're backlogging on TCP
connections or something along those lines?
[r...@rhl073 ipv4]# netstat -an | awk '/^tcp/ {A[$(NF)]++} END {for (I
in A) {printf %5d %s\n, A[I], I}}'
34723 TIME_WAIT
3 CLOSE_WAIT
275 FIN_WAIT1
74 FIN_WAIT2
8824 ESTABLISHED
815 SYN_RECV
102 CLOSING
30 LAST_ACK
10 LISTEN
In an effort to tune things, I've tried playing with the TCP timeout
settings a bit, and the response times have improved somewhat. Please
note that I've been testing response times using the loopback
interface to rule out any ethernet hardware issues.
echo 15 /proc/sys/net/ipv4/tcp_fin_timeout
echo 1 /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 /proc/sys/net/ipv4/tcp_tw_reuse
We're running prefork, and have configured the client settings to what
seem to be reasonable limits for our hardware.
IfModule prefork.c
StartServers 100
MinSpareServers100
MaxSpareServers 200
ServerLimit 1500
MaxClients1500
MaxRequestsPerChild 100
/IfModule
Any help or advice would be greatly appreciated.
-Travis
-
The official User-To-User support forum of the Apache HTTP Server Project.
See URL:http://httpd.apache.org/userslist.html for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
[us...@httpd] Can't get suexec to work on a userdir
Hi. I'm looking for some help with using suexec and userdir (2.2.15 on FC11).
I have this test script running in a userdir (~test44/public_html/test.php):
?php system('whoami'); ?
And it keeps reporting apache, not test44.
Suexec is enabled, as shown in error log file.
Per the documentation (http://httpd.apache.org/docs/2.2/suexec.html):
The only requirement needed for this feature to work is for CGI
execution to be enabled for the user and that the script must meet the
scrutiny of the security checks above.
When I access the test page, no errors are logged to the suexec.log
file, so it doesn't seem to be failing the security checks.
So either CGI execution is not enabled for users (how does one enable
that?), or else it's something else completely I'm missing.
I'll be glad to feel dumb in someone can tell me what it is! :) TIA!
Ken Tanzer
-
The official User-To-User support forum of the Apache HTTP Server Project.
See URL:http://httpd.apache.org/userslist.html for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
