I've run multiple apaches for the sake of testing and had the "test" server run on an unusual port. I always thought that was fine. I never had a reason to try and forward connections from a third server.

Why is running two servers on two different ports unacceptable for your situation?

--Pileofrogs

There is a large possibility that a second application, based on the first one, will permanently be added to this server. This would be two apache servers running full time. If we need to have test versions of those running at the same time, all of a sudden we have four apache servers running at once. That is why I am concerned about the scalability of this.

As far as a third server, the reason I came to that conclusion was because of this same possibility. I see there is no necessity for that now, it just seemed more cleanly organized in my mind to have one server doing the port forwarding and the others handling requests associated with their particular application. Otherwise, you have one apache server both handling the port forwarding and doing the work for its application. Again, not bad, just a little more convoluted.

I'm having a hard time visualizing a situation where you need to be running all these different versions at the same time. It is some sort of test or demo rig where you want to compare many versions to each other?

If I were doing something like that, I'd still just run a lot of apaches on different ports. I'd write a simple script that generated the config files, so adding new ones for new versions would be simple. That would solve the scalability problem. You could do something cute like encode the version number in the port number (e.g port 1001 eq version 1.001). The script that generates the apache configs could also make a few HTML files with links to all your apaches.

If, on the other hand you're doing something production, I gotta wonder why you want all these different versions running...

This type of setup is from two production systems running on the same box. The second system was based off of the first, and so has many of the same module names.

As we work towards a new release of each system, we must be able to demonstrate changes made without affecting the production system. Hence the need for the "test" versions.

I wanted to avoid basing the number of apache servers running on the number of applications running, as each server is one more thing to keep an eye on.

This is just the sort of thing I am looking for. Thanks ides!

If anyone else has any other ideas I would still greatly appreciate hearing them. I have learned a LOT about mod_perl with this investigation, as this is my foray into major development with it.

The problem is that each mod_perl process has a single perl interpreter embedded in it; any of those interpreters will have a single version of any given module in any given namespace which is required. Unless you flush what's loaded and re-require the module for each request (using something similar to Apache::StatINC, or whatever the mp2 analogue is) there's no guarantee that version n of Foo::Bar will be loaded instead of version m in the child httpd you get pointed at. Unless you work some kind of version number into your module filenames (and package declarations) you're either going to get the "wrong" version of something or you're going to be constantly clobbering and reloading (negating any benefits from the persistence of running under mod_perl).