Dear Guido, many thanks for Your answer.
It looks, like the parameter reply_timeout=1800000 was the solution. I added that parameter yesterday and was not sure if that would help and since I go to vacation in short time, I asked in this list in parallel to maybe solve the problem before vacation in another way. The documentation for reply_timeout (https://tomcat.apache.org/connectors-doc/reference/workers.html) says "By default (value zero) the webserver will wait forever which could be an issue for you." and it looks, like this really was an issue for us. It looks to me, like the JBoss backends do not give any reply to ajp requests sometimes(often?) and they are then kept established forever and pile up. They are not interpreted as idle, and therefore they do not get removed by JkWatchDog. Why the backend applications so often do not give any response, I think is another issue for the developers. But maybe the importance of changing the reply_timeout parameter from default value "infinit" to a even very high value of 30 min should be stated even more prominent in the worker documentation. > you wrote, you're using the worker MPM. What are the pool sizes for child > workers and it's threads, i.e. the values for ServerLimit, ThreadsPerChild? > And what's the minimum thread pool size, i.e. MinSpareThreads? /etc/apache2/mods-enabled/mpm_worker.conf <IfModule mpm_worker_module> StartServers 2 MinSpareThreads 25 MaxSpareThreads 75 ThreadLimit 64 ThreadsPerChild 35 MaxRequestWorkers 560 MaxConnectionsPerChild 10000 </IfModule> > But even if the number of connections is unexpected high -- this will not > consome more memory time by time after establishing. I don't know, but I started investigating the Apache because it nearly run out of RAM some days ago, as Nagios informed. And the RAM usage of Apache clearly correlates with the count of AJP connections, as the Nagios graphs show. Now, with connection pool cleanup working since yesterday, the count of AJP connections is radical lower then before, and also the RAM usage is radical lower in parallel :-) Many thanks again, and best regards, Hilde --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
