I have not had much opportunity over the past several years to play with IIS7 on Windows 2008. Most of my installs have been Apache/Tomcat/JBoss on Linux but this past week I got my chance to finally work on IIS7 a little more in-depth with an isapi_redirect-under IIS7-to-Tomcat 6 setup. My experience reminded me why I do still prefer working on Linux (or any UNIX) over Windows.
Although there are a few additional steps, getting the isapi_redirect Tomcat Connector installed and working under IIS7 isn't all that much different from setting it up under previous IIS versions. I do have to update it to account for these IIS7-specific configuration steps but using my HOWTO as a starting point, I got to the point where I'm scratching my head because everything should be working. Instead of seeing my expected HTML output, though, I received a nice, short "The service is unavailable" message whenever I tried loading the app's homepage.
The isapi_redirect logs were strange; containing one entry I had not seen before followed by another which is like an old friend:
[Timestamp] [PID:TID] [error] ajp_validate::jk_ajp_common.c (2686): worker ajp can't resolve tomcat address localhost
[Timestamp] [PID:TID] [error] ajp_send_request::jk_ajp_common.c (1630): (ajp) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=49)
"Worker ajp can't resolve tomcat address localhost"? Huh?
Well, tomcat was started and I could telnet to it's ajp connector port just fine so it certainly wasn't that! Tomcat is running on the same server IIS is running on so I couldn't blame the network or the firewall either.
Checking the hosts file under windows\system32\drivers\etc, I had two entries for localhost:
Assuming the tomcat connector was picking up the IPV6 entry for localhost because it was the last occurrence of localhost in the file, I commented it out, restarted IIS, and, suddenly, IIS is talking to Tomcat. Telling a co-worker about my discovery, I decided to see what would happen if I removed the comment from in front of the entry and restarted IIS again. Fully expecting it to fail again, it, however, continued working fine. It was almost as if I imagined the whole problem and all I can think is, "Some people prefer this over Linux?".
UPDATE: (09/06/12) I managed to come across a case where this doesn't work and I'm starting to think that from now on if I'm working with Windows servers, just set the worker host in workers.properties to 127.0.0.1 instead of localhost.