Bug 50551

Summary: Some proxied connections ignore ttl setting
Product: Apache httpd-2 Reporter: Slawo <s.janotta>
Component: mod_proxyAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED LATER    
Severity: normal Keywords: MassUpdate
Priority: P2    
Version: 2.2.17   
Target Milestone: ---   
Hardware: Sun   
OS: Solaris   
Attachments: DNS recheck patch

Description Slawo 2011-01-06 10:26:37 UTC
In the solution for bug #43371 a patch was provided to enable setting of smax=0.

Setting smax=0 ttl=30 doesn't seem to lead to dropping of the last connection, though.

My expectation would be, that if I set smax to 0 then each connection should be dropped after ttl expires.

Ways to reproduce:

1. Define a ProxyPass, e.g. like this:
NameVirtualHost 192.168.100.10:443
<VirtualHost 192.168.100.10:443>
    SSLEngine ON
    SSLProxyEngine ON
    ProxyPass / https://backend.mydomain.com:8080/ disablereuse=On
    ProxyPassReverse / https://backend.mydomain.com:8080/
</VirtualHost>

2. After making some requests to the proxy, change the ip-address of the server backend.mydomain.com

3. When you now make a new request, the new ip-address of the backend will be used.

4. Change the configuration to:
NameVirtualHost 192.168.100.10:443
<VirtualHost 192.168.100.10:443>
    SSLEngine ON
    SSLProxyEngine ON
    ProxyPass / https://backend.mydomain.com:8080/ smax=0 ttl=30
    ProxyPassReverse / https://backend.mydomain.com:8080/
</VirtualHost>

5. After making some requests change the ip-address of the server backend.mydomain.com and wait for a time much bigger than ttl.

6. When you now make new requests, some of the requests, but not all(!) still try to connect to the old ip-address of the backend.

Apparently not all connection have beed dropped after ttl expiry.
Comment 1 Olivier BOËL 2011-01-12 09:57:28 UTC
Hello, gents,


Apache 2.2.17 on Solaris 10 seems to ignore ttl.
Configuration file :
ProxyPass / http://prnsdv.appsrv:65245/ smax=0 ttl=5
A network capture shows that the back-end connection is closed by the remote server (prnsdv.appsrv) after 20 seconds (Tomcat ConnectionTimeout).

Did anybody ever succeed to configure this ttl?

TIA,


Olivier
Comment 2 Olivier BOËL 2011-01-12 10:15:47 UTC
My mistake : I was expecting Apache to close automatically the connection after 5 seconds, but, looking at apr_reslist.h, I read :
 * @param ttl If non-zero, sets the maximum amount of time in microseconds an
 *            unused resource is valid.  Any resource which has exceeded this
 *            time will be destroyed, either when encountered by
 *            apr_reslist_acquire() or during reslist maintenance.
Indeed, I observed that :
1. if 2 requests are received in less than ttl seconds, Apache re-uses the existing connection
2. if there are more than ttl seconds between 2 requests, Apache closes the established connection and creates a new one

So, ttl works as expected.

Great!
Comment 3 Jeff Trawick 2011-01-12 10:37:23 UTC
FYI...  The proxy ttl parameter documentation was updated as follows in trunk r1058192.

Index: mod/mod_proxy.xml
===================================================================
--- mod/mod_proxy.xml	(revision 1058185)
+++ mod/mod_proxy.xml	(working copy)
@@ -994,8 +994,9 @@
     <tr><td>ttl</td>
         <td>-</td>
         <td>Time to live for inactive connections and associated connection
-        pool entries, in seconds.  Those which are unused for at least
-        <code>ttl</code> seconds will be destroyed.
+        pool entries, in seconds.  Once reaching this limit, a
+        connection will not be used again; it will be closed at some
+        later time.
     </td></tr>
 
     </table>
Comment 4 Slawo 2011-03-14 05:17:21 UTC
Hi,
I am still having problems with the smax setting.
While the setting of ttl works for most of the connections, I have the feeling that probably the last one isn't taken out of the pool and isn't put into the "destroy later" group.
Can anyone try to reproduce my settings and confirm/disconfirm my finding?
Comment 5 Slawo 2011-04-01 10:00:19 UTC
Hi everybody,
I have now been able to track down the reason for the bug.
The problem is that we are using the prefork model Apache.
If I use the worker model, the problem is gone.

I have analyzed the source of the mod_proxy module and found this inside mod_proxy.h:

/* Connection pool */
struct proxy_conn_pool {
    apr_pool_t     *pool;   /* The pool used in constructor and destructor calls */
    apr_sockaddr_t *addr;   /* Preparsed remote address info */
#if APR_HAS_THREADS
    apr_reslist_t  *res;    /* Connection resource list */
#endif
    proxy_conn_rec *conn;   /* Single connection for prefork mpm's */
};

Apparently, when using the prefork model, the ttl and smax setting are not applied to the *conn entry.

I don't know if this is possible at all, but is there a reason that this connection doesn't expire?

In fact, what we really need is not an option for expiry of the connections after idle timeout. We would rather very like to have an option to refresh the IP-address of the connections in case the DNS resolver delivers a different address.

There is such an option in the mod_weblogic module for Weblogic. It's named WLDNSRefreshInterval and would be very useful in the mod_proxy module, too.
Comment 6 slawomir.janotta 2011-05-19 11:28:09 UTC
Created attachment 27034 [details]
DNS recheck patch

Please find attached a patch which addresses the DNS chaching issue.

This is a description of the approach used:
1. As I didn't find any place where I could put an arbitrarily executed timer, I decided to go with a Boolean option to enable/disable the DNS address issue resolving. I have kept the option by now to be a timer however, to be able to change it if someone tells me how to implement it.
2. I have put the handling code into the function ap_proxy_release_connection() of module proxy_util.c
3. The code makes a call to apr_sockaddr_info_get() to check if the destination address has changed. If it has changed, the change is propagated to all places I thought to be relevant and then the connection in question is marked as being due to be closed.

There are several issues with the patch however, since I am by no means experienced enough with the Apache code to make sure it is the best solution.
The main issues I can think of (And you will for sure find others) are:
A. Is this the right place to put such a check?
B. Is it possible to have a timer to do this check instead?
C. Is the pool handling correct or does it lead to a memory leak?
D. Is the method to clean up and close the connections with obsolete ip addresses (the last four lines of the code above the call to connection_cleanup(conn, s)) the right approach?
Comment 7 William A. Rowe Jr. 2018-11-07 21:08:58 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.