Apache version:    2.2.3

JBoss version:      5

JBoss Web:         2.1.3.GA <http://2.1.3.ga/>

mod_jk:               1.2.30



Dear community,



We are having a Wicket-based Java application deployed in a production
server cluster using Apache (2.2.3) with mod_jk (1.2.30) as load balancing
component w/ sticky session and Jboss 5 as application container for the
Java application.



We are inconsistently seeing an issue in our production environment where
our AJP queues between Apache and Jboss as shown in the JMX console fill up
with requests to the point where the application server is no longer taking
on any new requests. When looking at all involved system components (overall
traffic, load db, process list db, load of all clustered application server
nodes) nothing points towards a capacity issue which would explain why the
calls are being stalled in the AJP queue. Instead all systems appear
sufficiently idle.



So far, our only remedy to this issue is to restart the appservers and the
load balancer which only occasionally clears the AJP queues.



We are trying to figure out why the queues are filling up to the point that
no calls get returned to the end user although the system is not under a
high load.



Has anyone else experienced similar problems?

Are there any other system metrics we should monitor that could explain the
queuing behavior?

Is this potentially a mod_jk issue? If so, is it advisable to swap mod_jk
with mod_cluster to resolve the issue?



Any advice is highly appreciated. If I can provide additional information
for the sake of troubleshooting I would be more than willing to do so.



/Ben





*Ben Knight*
System Engineer • Fi



*T:* +1 212 941 5220 / *M:* +1 917 664 0297
ben.kni...@f-i.com / www.f-i.com



This communication is confidential and is only intended for
the use of the individual or entity to which it is directed.
It may contain information that is privileged and exempt from
disclosure under applicable law. If you are not the Intended
recipient, please notify us immediately. You should not copy
it or disclose its content to any other person.

Reply via email to