httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject AW: Problem with DNS lookup caching in reverse proxy
Date Mon, 02 May 2011 09:26:06 GMT
Hi Igor and everybody :-)
Unfortunately, this is exactly what won't work for me.
The point is: In our case the remote address is still valid. The "old" node is not to be shut
down so the connection to it is technically still valid. Instead, the full qualified address
if looked up via the resolver now points to a "new" node. If I'm correct, in this case there
won't be any error. And if there is a lot of traffic on the connection, there also won't be
any timeout and the connection will be happy accessing the "old" node because it simply uses
the stored ip-address and doesn't see any reason to discard it. If I set ttl to say 1 second
(way too small for me in fact) and the connection is accessed every 100ms, there is no way
to timeout the connection. The only solution I can think of is to force the expiry after a
set timeout.
Having said that I would like to ask some additional help with implementing such a solution.
Unfortunately, I'm pretty new to Apache and have to work it out "the hard way". So far I have
worked out how to enable the additional parameter for the mod_proxy. I have done it by adding
the setting dnsto (for DNS timeout) to the structure proxy_worker in mod_proxy.h. The question
is: where can I register the timeout to be used and how do I force the worker to re-resolve
the address.

-----Ursprüngliche Nachricht-----
Von: Igor Galić [] 
Gesendet: Dienstag, 26. April 2011 23:45
Betreff: Re: Problem with DNS lookup caching in reverse proxy

----- Original Message -----
> Hello everybody,
> I have tried to solve my issue by contacting the users@ mailing list
> but meanwhile I think this is the more appropriate list to address
> it.
> I have issues with the mod_proxy resolving a full qualified
> servername via DNS and caching it in its connection pool so a change
> in the resolver doesn't get noticed by mod_proxy. After trying all
> the different possibilities that came to mind I'm back at where it
> all started.
> I still cannot find a solution to the problem that mod_proxy caches
> the IP address resolved by DNS and thus doesn't acknowledge all
> changes to it. With the help of Igor Galić on the users@ mailing
> list and by means of Bug Report 50551 I am able to get about 95% of
> the cases solved. But there still are cases where the resolved
> address won't be changed.
> But first let me describe the configuration more deeply:
> What we have is a configuration where the Apache Reverse Proxy (RPX)
> is used to allow transparent switch of the backend JEE server. We
> solve this by configuring an alias to the service on the backend.
> The alias is then entered in whatever DNS resolver we use to point
> to the one system which is currently meant to receive the request.
> This allows us to make application changes on one system while the
> other is still working, then transparently switching to the updates
> server to do maintenance on the other.
> Now the problem with this is that Apache, or more exactly the
> mod_proxy, has a connection pool mechanism which apparently binds to
> a once resolved IP address "forever". See the type struct
> proxy_conn_pool in file mod_proxy.h or just my description in Bug
> Report 50551.
> It appears to me, and I believe I was able to show this by extensive
> testing, that the member variable apr_sockaddr_t *addr /* Preparsed
> remote address info */
> in this struct is responsible for this behavior and that this
> preparsed remote address is invalidated only if the last pooled
> connection in this connection pool is timed out.
> In my opinion the best solution to this problem would be to add an
> additional perameter to mod_proxy to force a renewal of the DNS
> resolve procedure for this address after a set timeout like it is
> possible in mod_weblogic. Unfortunately this is way beyond my

Instead of re-resolving after a set timeout, it would make sense
to re-resolve after a timeout occured, marking the worker in error.

The only question is: Is that the struct shared across the pool?

> capabilities at the moment to implement it myself. But I wonder why
> there seems to be no need for such an option so nobody implemented
> it yet. Perhaps there is another I'm still not aware of?
> Regards
> Slawo

Dieses E-Mail von PostFinance ist signiert. Weitere Informationen finden Sie unter:
Geben Sie Ihre Sicherheitselemente niemals Dritten bekannt.
View raw message