Summary: | Some proxied connections ignore ttl setting | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Slawo <s.janotta> |
Component: | mod_proxy | Assignee: | 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
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 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! 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> 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? 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. 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?
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. |