Run Multiple Python mod_wsgi Websites With Apache On Windows

Yes, this sounds completely crazy, but there is a semi-valid need to do this, unfortunately. However, when you need to run multiple Python websites on Apache on Windows via mod_wsgi, it quickly becomes apparent that using the typical <VirtualHost> configuration options do not work as expected.

When you try to do it with a <VirtualHost> configuration, you will be unable to setup a separate WSGIPythonPath configuration setting per virtual host, as that configuration directive is not allowed within a <VirtualHost> node. Instead, you have a single WSGIPythonPath for your entire Apache instance.

If you determine that a single WSGIPythonPath will not work for each website you are hosting separately, the only solution I have found so far is to setup multiple Apache services, each running on its own IP Address/Port combination. If you are running Apache 2.2 on a 64-bit version of Windows, you can run the following to setup a new Apache service:

"%SystemDrive%\Program Files(x86)\Apache Software Group\Apache 2.2\bin\httpd.exe" -k install -n "Apache 2.2-Secondary" -f "%SystemDrive%\Program Files(x86)\Apache Software Group\Apache 2.2\conf\httpd_secondary.conf"

Once the service is installed properly, you just need to make sure to put your configuration options in httpd_secondary.conf and then start the service, and you now have two separate Apache webservers running two separate mod_wsgi Python websites on the same Windows computer.

Tags:

Related Posts

Jul 15, 2014
2 minutes

The Easiest Way to Create A Solution That Works

The easiest way to create a solution that works…is to do it right the first time. Yes, this is a bit of a cop-out, but it turns out to be an important factor to keep in mind when you are tempted to come up with a quick and dirty solution for a problem that does not follow established best practices and is likely to have code quality issues later.

I have run across many sections of code that I or other developers have written in the past that we thought were “good enough” at the time it was written, yet, I was revisiting the code because we discovered a bug in it. Many times, this code had an issue that would have been trivial to fix at the time it was written, if it were only found. It seems that as a developer, we tend to find the least sufficient solution that will solve the immediate problem we are experiencing instead of finding an optimal solution that will be easily maintained months and years after it was written.

#responsive-web-design #rant #web-development
Read More
Mar 27, 2014
One minute

jQuery.hover Issues in Internet Explorer on Windows 7

When creating a new mega-dropdown menu for a site I was working on, I used jQuery’s .hover event to trigger which content the menu was displayed. This seemed to work as expected in most browsers that I tested in, except for one, Internet Explorer. Unfortunately, it wasn’t even in every instance of Internet Explorer.

Windows 7

After Windows Vista came out as one of the biggest duds that the world has ever seen, Windows 7 was a ringing success. Windows 7 is an extremely functional and useful Operating System in the vein of Windows XP, but during testing of this website, we found one troubling issue with every version of Internet Explorer we installed on it. When you hovered over the menu and triggered the jQuery.hover() event, Internet Explorer seemingly locked-up for a few seconds, making the entire browser unresponsive. In a stroke of strange luck, I was unable to reproduce this functionality in Internet Explorer on Windows 8 or 8.1, so this is something that only affects the older operating systems. The fix is to replace jQuery.hover() with jQuery(document).on(“mouseenter”) and call the appropriate function as well.

#internet-explorer #jquery #windows-7
Read More
Mar 11, 2015
One minute

Firefox 36 Has A Massive Memory Leak

While looking through our TrackJS logs the other day, I ran across a peculiar error message coming from Firefox 36 on Windows 7. The error message was simply out of memory. It seemed that the pesky local storage issue had reappeared mysteriously. However, with a quick check of the codebase, I verified that no one had accidentally reverted those fixes.

With that possible cause ruled out, I turned to a developer’s best friend, Google, for solutions. Well, it appears that Firefox 36.0.0 has quite the memory leak issue. When looking into the detail of the issue, it became highly probably that this issue was the cause of the errors in our monitoring tools. Apparently, this bug rears its ugly head when you are doing 2D rendering on your page, and the site uses a 2D charting library to present information.

#javascript #firefox #web-development
Read More