in reply to Your wisdom on what to do with Apache 2.2 (eol) + mod_perl on Windows 64

I got a similar problem. From what I have read, some are installing the new Apache 2.4 and with a redirect rule, redirecting all old perl cgi requests to the old Apache 2.2 server (but at a performance hit, due to an extra server in the chain, but this backserver does not need to serve static files anymore, so it could balance out). This way, when/if mod_perl becomes available, they can switch more easily. Of course, the old Apache only accepts incoming connections from that new Apache, thus, making it less risky (when patches stop, pun intended).

edit: Apache began as a-patchy-server (explaining the pun)

edit2: Compile ourselves: Yes, Windows world is a bit different (but tell me what to do after the nmake and I'll give it a shot): The houses that offer Apache pre-compiled still do not bundle nor offer it (I checked a few weeks ago, it could be different now).

edit3: Or you just jump the gun, hire some temporal staff to help migrate and write a wrapper for your perlscripts to accept mod_proxy_fcgi.

  • Comment on Re: Your wisdom on what to do with Apache 2.2 (eol) + mod_perl on Windows 64

Replies are listed 'Best First'.
Re^2: Your wisdom on what to do with Apache 2.2 (eol) + mod_perl on Windows 64
by RayHunter (Acolyte) on Dec 10, 2016 at 10:55 UTC

    Thanks.

    I also checked, and there were no pre-compiled binaries out there yet, nor hints on using mod_perl on 2.4. Nothing post 2013 in fact. I know it's not broken yet, but when it does break we're going to have a lot to fix

    We generally don't need all of the functions of mod_perl: just the speed. FastCGI functionality would probably suffice, but as you say, there's the not insignificant cost of porting large existing (10000+ line) code base, and information on running FastCGI/ Apache on windows is also pretty scarce from what I can see.

    An alternate path is to port to Linux, as support of Linux in corporate hosting has improved. Especially as a VM.