While optimizing the configuration in Apache HTTP Server, mod_jk, mod_proxy, mod_cluster and JBoss Platform typically resolves any and all problems and errors in load balancing, there are exceptions (such as long running servlets that require additional optimization).
In most cases, a correctly tuned configuration is the catch all for mod_jk issues. This section discusses some problems and how the configuration can be improved to avoid them.
Common Problems
The list below outlines some common configuration problems. Ensuring your implementation is not subject to one of these may assist to resolve your issue.
A firewall between Apache HTTP Server and JBoss Enterprise Application Platform
If there is a firewall between Apache HTTP Server and JBoss Enterprise Application Platform and no socket_keepalive parameter is set, the firewall can close connections unexpectedly.
example:
worker.node1.socket_keepalive=1
JkShmFile on a NFS share
Placing the JkShmFile on a NFS share can cause unexplained pauses in mod_jk and odd behavior. It is strongly recommended that the JkShmFile always be placed on local storage to avoid problems.
No CPing/CPong set
The CPing/CPong property in mod_jk is the most important worker property setting, allowing mod_jk to test and detect faulty connections. Not setting this parameter can lead to bad connections not being detected as quickly which can lead to web requests behaving as if 'hung'.
example:
worker.node1.ping_mode=A
Running an old version of mod_jk.
There are known issues with sticky sessions in versions prior to mod_jk 1.2.27.
MaxClients higher than maxThreads
Setting the MaxClients parameter in Apache HTTP Server higher than the maxThreads setting in JBoss (with a high load on the server) will result in Apache HTTP Server overwhelming the JBoss instance with threads which will cause hung and/or dropped connections.
No connectionTimeout parameter set
The connectionTimeout parameter set in JBoss is required for proper maintenance of old connections.
Running an older version of EAP.
There is a bug in EAP 4.2 base and EAP 4.2 CP01 which causes sockets to be left in the CLOSE_WAIT state, thus causing the appearance of hung requests again. This issue has been reported and fixed https://jira.jboss.org/jira/browse/JBPAPP-366
