httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <slawomir.jano...@postfinance.ch>
Subject Problem with DNS lookup caching in reverse proxy
Date Tue, 19 Apr 2011 10:31:00 GMT
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 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



-----Ursprüngliche Nachricht-----
Von: Slawomir R. Janotta [mailto:s.janotta@aviope.de] 
Gesendet: Freitag, 3. Dezember 2010 16:54
An: users@httpd.apache.org
Betreff: Re: [users@httpd] Problem with DNS lookup caching in reverse proxy

>
> Would it be a viable option for you to not use the DNS method, and
> instead do something like:
>
> <Proxy balancer://notsohotcluster>
>   BalanceMember https://backend1.mydomain.com:8080/
>   BalanceMember https://backend1.mydomain.com:8080/ status=+H
> </Proxy>
>
> ProxyPass / balancer://notsohotcluster
> ProxyPassReverse / balancer://notsohotcluster
>
> This will (probably) simply mitigate the DNS problem.
>
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
>
>
Thank you very much, Igor.
Indeed, your suggestion solves most of the cases where I encounter the
switch-over of the backend hosts.
However, this does *not* help in all cases, as this works only if the
backend is no more reachable and thus an error condition occurs. Sometimes
I just want to switch from one backend to the other without shutting any
of them. A working TTL in the connection pool or in the DNS cache would be
ideal for this.
Perhaps I have to open a new Bug report in Bugzilla.
Regards
Slawo.


Sicherheitshinweis:
Dieses E-Mail von PostFinance ist signiert. Weitere Informationen finden Sie unter: 
https://www.postfinance.ch/e-signature.
Geben Sie Ihre Sicherheitselemente niemals Dritten bekannt.
Mime
View raw message