[SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?

[Hildegard Meier <da...@gmx.de>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: [SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?

[Jäkel, Guido <G....@dnb.de>]

>From: Hildegard Meier [mailto:daku8938@gmx.de]
>Sent: Thursday, September 01, 2016 10:14 AM
>To: users@tomcat.apache.org
>Subject: [SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has
>no effect?
>
>Dear Guido,
>
>many thanks for Your answer.

many thanks for your feedback, too.

>
>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.
>[...]
>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.

I set this even lower (to 120s) because it's said it's the timeout for reading of each packet and no application on the Tomcat should take so much time to send any part of an answers.

I might be of worth if you pass the URIs of the dangling requests to developers. Because not finished, they are not logged. But you may take a look on the scoreboards of the Apache or the Tomcat. On Tomcat, it available via an MBean, you may read out it via JMX or via the http-proxy of the Tomcat Manager application. I may send you a script as a pointer, if you like.

Guido