Apache load balancer limits with Tomcat over AJP

<Proxy balancer://mycluster>
  BalancerMember ajp://10.176.201.9:8009 keepalive=On retry=1 timeout=1 ping=1
  BalancerMember ajp://10.176.201.10:8009 keepalive=On retry=1 timeout=1 ping=1
  BalancerMember ajp://10.176.219.168:8009 keepalive=On retry=1 timeout=1 ping=1
</Proxy>

BalancerMember ajp://host1:8280 route=jvmRoute-8280 connectiontimeout=10 retry=600




Solution for this Problem is pretty simple:

add to Proxypass:

BalancerMember ajp://10.176.201.9:8009 keepalive=On ttl=60

add to Tomcats Server.xml:

Connector port="8009" protocol="AJP/1.3" redirectPort="8443 connectionTimeout="60000"

After these changes everything should be work fine :-)





I did not see the timeout value on the Apache log you pasted. If it is 300, try changing it to 1200. We had the same problem and changing the timeout on Apache httpd.conf file from 300 to 1200 fixed it.








Description:
Enables HTTP persistent connections
Syntax:
KeepAlive On|Off
Default:
KeepAlive On
Context:
server config, virtual host
Status:
Core
Module:
core


The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over the same TCP connection. In some cases this has been shown to result in an almost 50% speedup in latency times for HTML documents with many images. To enable Keep-Alive connections, set KeepAlive On.

For HTTP/1.0 clients, Keep-Alive connections will only be used if they are specifically requested by a client. In addition, a Keep-Alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI pages, and server-generated directory listings will generally not use Keep-Alive connections to HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.



When a client uses a Keep-Alive connection it will be counted as a single "request" for the MaxConnectionsPerChild directive, regardless of how many requests are sent using the connection.


KeepAliveTimeout Directive

Description:
Amount of time the server will wait for subsequent requests on a persistent connection
Syntax:
KeepAliveTimeout num[ms]
Default:
KeepAliveTimeout 5
Context:
server config, virtual host
Status:
Core
Module:
core
Compatibility:
Specifying a value in milliseconds is available in Apache httpd 2.3.2 and later


The number of seconds Apache httpd will wait for a subsequent request before closing the connection. By adding a postfix of ms the timeout can be also set in milliseconds. Once a request has been received, the timeout value specified by the Timeout directive applies.

Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.

In a name-based virtual host context, the value of the first defined virtual host best matching the local IP and port will be used.






ProxyTimeout Directive

Description:
Network timeout for proxied requests
Syntax:
ProxyTimeout seconds
Default:
Value of Timeout
Context:
server config, virtual host
Status:
Extension
Module:
mod_proxy


This directive allows a user to specifiy a timeout on proxy requests. This is useful when you have a slow/buggy appserver which hangs, and you would rather just return a timeout and fail gracefully instead of waiting however long it takes the server to return.

On the Apache docs page, the *nofailover* parameter has the following
description:
"*If set to **On** the session will break if the worker is in error state or
disabled. Set this value to On if **backend** servers do not support session
replication*.".


I can also find this explanation:
"*(...) **Basically, **nofailover** Off means if the instance that the
session is associated with goes down/becomes unreachable, then redirect the
user to the next available instance. The user will lose their session
information (unless you have set up session replication in **jBoss**- that's
another topic) but will not get a white page. If you set this to On,
individual users will get a 503 error if their server goes down. (...).*"


By "googling", it also looks that Mondo <https://mondo.su.se/portal> (the
sakai installation from the Stockholms Universitet) is using
*stickysession=JSESSIONID
nofailover=Off*
(here<https://roundup.it.su.se/confluence/display/sakaisam/apache-config>
).

So, apparently, it looks like it is safe to use *nofailover=Off* when load
balancing Sakai with mod_proxy_balancer.

*Can anyone using this setting in production confirm this?*