Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of i.galic@brainsware.org
 designates 188.40.115.121 as permitted sender)
Date: Tue, 26 Apr 2011 21:44:49 -0000 (UTC)
From: Igor =?utf-8?Q?Gali=C4=87?= <i.galic@brainsware.org>
To: dev@httpd.apache.org
Subject: Re: Problem with DNS lookup caching in reverse proxy
Message-ID: <ceffa018-bbe5-412c-8d68-3749b3a1d820@iris>
In-Reply-To: <17774898.413.1303209067197.JavaMail.postmaster@post.ch>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


----- 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=C4=87 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
> 
> 
> 
> -----Urspr=C3=BCngliche 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=3D+H
> > </Proxy>
> >
> > ProxyPass / balancer://notsohotcluster
> > ProxyPassReverse / balancer://notsohotcluster
> >
> > This will (probably) simply mitigate the DNS problem.
> >
> >
> > i
> >
> > --
> > Igor Gali=C3=84=E2=80=A1
> >
> > 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.

-- 
Igor Gali=C4=87

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/