Problem when used with a reverse proxy

gemlog 18 Mar, 2011
This is not a bug, per se, just because it's not probably a normal/common thing to do. I'm just posting this in case someone else decides to migrate their site to a new server doing the same thing.

As you know, one of the problems when moving a site from one server to another is dealing with the ip change. There's always some kind of delay before everyone has the new ip for the website simply because of how DNS works. Reducing the TTL (time to live) at the nameserver is a good method of minimizing downtime, but you don't always have access to the SOA record or the DNS host may not allow you to set very low TTL times.

In combination with the above method (or stand-alone if you can't change the TTL) is to use a reverse proxy. In simple, you tell the webserver on the old box (apache in my case) to continue to answer for, but to ask the new server for the actual pages to serve. This way the site appears to be up for people knowing the new ip and also for people with the old ip address in their DNS. Seamless and beautiful.

This is what an entry might look like in your vhost stanza for

ProxyRequests Off                  
<Proxy *>                          
Order deny,allow
Allow from all
ProxyPass /
ProxyPassReverse /
ProxyPass /
ProxyPassReverse /

The thing that makes that impossible looking proxy work, is that you edit /etc/hosts on the old server and make two entries for with the ip of the new server.

This worked perfectly for me on 3 or 4 joomla sites until I hit one site -- a site with CC on its front page: couldn't connect to db. Everything else worked, but not that module. Since I hadn't touched the dns yet, I quickly commented out the proxy and did a graceful reload of apache. Surprise! Still broken in just the same way. Weird.

Finally (some time passed...), I noticed that everything was showing coming from the logging monitor for the old server except the CC request -- that was showing on the logging monitor for the new server. After commenting out the /etc/hosts entries, the site again worked properly on the old server.

So, it seems that perhaps (I really don't know) ChronoConnectivity is doing its own lookup somewhere, which makes proxying impossible using the method described above. Maybe it's not even CC's problem, it may be inherent in how it has to make db connections. I haven't seen such a problem with any other modules or components, but needless to say, nothing else has the functionality that CC does. Then again, it could be something to do with mod_customcontent -- I truly have no idea -- nothing but relative links in anything I typed.

As I said, not a bug per se, just an oddity I'm posting in case someone else runs into the same problem.

GreyHead 18 Mar, 2011
Hi gemlog,

That you - not an area that I know anything about. From my digging in the CC code a while back I think all the DB calls in CC use the standard Joomla! code - but I do remember that there were a lot of repeated call - the code is far from optimised.

I don't have any helpful suggestions though :-(

gemlog 18 Mar, 2011
Not a big deal Bob, just stumped me for a bit. That site will just have to go without having that module up until the dns expires for the old ip. I'm going to wait until Monday when it will impact the fewest skiers. I only posted it for general interest in case I can save someone else from scratching their head over it.
This topic is locked and no more replies can be posted.