----- 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 > > > > -----Ursprüngliche Nachricht----- > Von: Slawomir R. Janotta [mailto:s.jano...@aviope.de] > Gesendet: Freitag, 3. Dezember 2010 16:54 > An: us...@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.ga...@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ć Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
