-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeffrey,
On 4/4/14, 1:09 PM, Jeffrey Janner wrote: >> -----Original Message----- From: Jeffrey Janner >> [mailto:jeffrey.jan...@polydyne.com] Sent: Friday, April 04, 2014 >> 12:04 PM To: 'Tomcat Users List' Subject: RE: AW: AW: >> tomcat-connectors-1.2.39-windows-x86_64-iis does not work >> >>> -----Original Message----- From: Christopher Schultz >>> [mailto:ch...@christopherschultz.net] Sent: Friday, April 04, >>> 2014 10:23 AM To: Tomcat Users List Subject: Re: AW: AW: >>> tomcat-connectors-1.2.39-windows-x86_64-iis does not work >>> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> Jeffrey, >>> >>> On 4/4/14, 10:50 AM, Jeffrey Janner wrote: >>>>> -----Original Message----- From: André Warnier >>>>> [mailto:aw@ice- >>> sa.com] >>>>> Sent: Thursday, April 03, 2014 5:27 PM To: Tomcat Users >>>>> List Subject: Re: AW: AW: >>>>> tomcat-connectors-1.2.39-windows-x86_64-iis does not work >>>>> >>>>> Christopher Schultz wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> André, >>>>>> >>>>>> On 4/3/14, 3:34 PM, André Warnier wrote: >>>>>>> Alten, Jessica-Aileen wrote: >>>>>>>>> -----Ursprüngliche Nachricht----- Von: André >>>>>>>>> Warnier [mailto:a...@ice-sa.com] Gesendet: >>>>>>>>> Donnerstag, 3. April 2014 15:36 An: Tomcat Users >>>>>>>>> List Betreff: Re: AW: >>>>>>>>> tomcat-connectors-1.2.39-windows-x86_64-iis does >>>>>>>>> not work >>>>>>>>> >>>>>>>>> Alten, Jessica-Aileen wrote: >>>>>>>>>>> A bit guessing here : >>>>>>>>>>> >>>>>>>>>>> You have : >>>>>>>>>>>> worker.ajp13w.host=localhost >>>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>>>> jk_open_socket::jk_connect.c (735): connect >>>>>>>>>>>> to 0.0.0.0:8009 >>>>>>>>> failed >>>>>>>>>>>> (errno=49) >>>>>>>>>>> is "localhost" == 0.0.0.0 ? >>>>>>>>>>> >>>>>>>>>>> From the point of view of mod_jk/isapi, should >>>>>>>>>>> it not be >>>>>>>>> "127.0.0.1" ? >>>>>>>>>> Your answer points to the right direction. >>>>>>>>>> 0.0.0.0 means: any configured IPv4-Address on >>>>>>>>>> this computer, see >>>>>>>>>> >>>>>>>>>> http://serverfault.com/questions/78048/whats-the-difference- >>>>> >>>>>>>>>> >>> >>>>>>>>>> betwee >>>>>>>>>> n- >>>>>> ip >>>>>>>>>> -addre ss-0-0-0-0-and-127-0-0-1 >>>>>>>>>> >>>>>>>>>> In principle this is ok at first. The Ajp13 >>>>>>>>>> Connector was configured in server.xml to listen >>>>>>>>>> at any IPv4 address on >> port >>>>>>>>>> 8009 - which is the default setting. But the >>>>>>>>>> connector can't find any suitable >>>>>>>>> address. >>>>>>>>>> The problem is: The new Tomcat-Connector can't >>>>>>>>>> parse "worker.ajp13w.host=localhost", instead >>>>>>>>>> localhost must be >>>>> replaced >>>>>>>>>> with "127.0.0.1", this works! >>>>>>>>>> >>>>>>>>>> In my eyes this is a big fat bug, because most >>>>>>>>>> documentation on workers use "localhost". >>>>>>>>>> localhost is actually the default for >>>>> the >>>>>>>>>> "host" connection directive. >>>>>>>>>> >>>>>>>>>> The new worker directive "prefer_ipv6" doesn't >>>>>>>>>> change this behavior. >>>>>>>>>> >>>>>>>>> Hi. >>>>>>>>> >>>>>>>>> Can you please really check this ? >>>>>>>>> >>>>>>>>> Open a command window on that server, and do "ping >>>>>>>>> localhost". >>> It >>>>>>>>> should tell you what it understands by "localhost". >>>>>>>>> Copy and paste the result here : >>>>>>>> ping localhost >>>>>>>> >>>>>>>> Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit >>>>>>>> 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 >>>>>>>> Zeit<1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 >>>>>>>> Zeit<1ms TTL=128 >> Antwort >>>>>>>> von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128 Antwort von >>>>>>>> 127.0.0.1: Bytes=32 Zeit<1ms TTL=128 >>>>>>>> >>>>>>>> Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, >>>>>>>> Empfangen = >>> 4, >>>>>>>> Verloren = 0 (0% Verlust), Ca. Zeitangaben in >>>>>>>> Millisek.: >> Minimum >>> = >>>>>>>> 0ms, Maximum = 0ms, Mittelwert = 0ms >>>>>>>> >>>>>>>> >>>>>>> That /is/ bizarre. As far as I know, to resolve >>>>>>> hostnames in >> its >>>>>>> configuration, mod_jk/isapi is using the OS's resolver >>>>>>> library, >>> the >>>>>>> same as the one "ping" should be using. On the other >>>>>>> hand, you say that if you have >>>>>>> >>>>>>>>>>>> worker.ajp13w.host=localhost >>>>>>> it doesn't work (mod_jk cannot connect to tomcat), but >>>>>>> when you change this to >>>>>>> >>>>>>>>>>>> worker.ajp13w.host=127.0.0.1 >>>>>>> then it works fine. >>>>>>> >>>>>>> Ok, another check in a command window (and I assume >>>>>>> that you >> open >>>>>>> this command window *on the server itself* where mod_jk >>>>>>> and Tomcat are running, right ?) >>>>>>> >>>>>>> test : >>>>>>> >>>>>>> 1) telnet localhost 8009 >>>>>>> >>>>>>> 2) telnet 127.0.0.1 8009 >>>>>>> >>>>>>> Any difference between these 2 cases ? >>>>>>> >>>>>>> If not, then indeed it looks like a >>>>>>> mod_jk/isapi_redirect 1.2.39 problem. >>>>>>> >>>>>>> In any case, you cannot "connect to" 0.0.0.0, as this >>>>>>> log line would suggest : >>>>>>> >>>>>>>>>>>> jk_open_socket::jk_connect.c (735): connect >>>>>>>>>>>> to 0.0.0.0:8009 >>>>>>>>> failed >>>>>> >>>>>> Could this be an interaction between IPv4 and IPv6? Try: >>>>>> >>>>>> C:> nslookup localhost >>>>>> >>>>>> You might get only 127.0.0.1 or you might also get :: >>>>>> (or something equivalent). I'm not sure why it wasn't >>>>>> happening with earlier versions of mod_jk (which?). >>>>>> >>>>> (versions : her first post mentioned the versions she was >>>>> comparing) >>>>> >>>>> I previously asked Jessica-Aileen to do a "ping localhost" >>>>> on the machine, see results above. It definitiely pings >>>>> 127.0.0.1 .. (assuming it was done on the same machine) >>>>> >>>>> And I don't think that nslookup uses the local resolver. >>>>> When I'm doing that on my Windows laptop, for "localhost" >>>>> it responds "not found" (in many more German words) >>>>> >>>>> C:\Dokumente und Einstellungen\aw>nslookup localhost >>>>> Server: fire-see.localdomain Address: 192.168.245.253 >>>>> >>>>> *** localhost wurde von fire-see.localdomain nicht >>>>> gefunden: Non- existent domain >>>>> >>>>> On the other hand, it does this (spot the difference..): >>>>> >>>>> C:\Dokumente und Einstellungen\aw>nslookup localhost. >>>>> Server: fire-see.localdomain Address: 192.168.245.253 >>>>> >>>>> Name: localhost Address: 127.0.0.1 >>>>> >>>>> (But that of course could be the "localhost" of my DNS >>>>> server, since it happens to be a Linux box running dnsmasq, >>>>> and it has >> that >>>>> name >>> in >>>>> it's own hosts file.) >>>>> >>>> This result is understandable, as the nslookup tool is a DNS >>>> resolver tool. It's designed to query the DNS system >>>> directly, avoiding the systems resolver and any caching. Not >>>> exactly sure why it resolves "localhost.", but adding the >>>> final period tells it not to append the default domain. In >>>> other words, localhost. Is a top- >> level domain. >>>> Perhaps there is a special case built into the DNS system for >>>> that. The difference here is that the resolver is going to >>>> search DNS and the local hosts table, usually with the local >>>> hosts table (/etc/hosts in *nix) taking precedence. I've not >>>> followed the complete thread, >>> but >>>> if the server is a *nix implementation, the better diag tool >>>> might be dig. And yes, I would not expect the address 0.0.0.0 >>>> on a client to connect to the localhost. That is a special >>>> case address >> meaning >>>> "local network". If anything, it would be sending packets out >>>> the NIC card, not via loopback. >>> >>> 0.0.0.0 means "all IPv4 interfaces available" and only applies >>> for binding a server socket. You can never connect to "0.0.0.0" >>> as a client. >>> >> Chris - It actually has a different meaning based on use. For >> binding to a socket in the local IP stack, it means what you >> say. In the routing table, it means the default route. In >> firewalls/routers, it probably means something completely >> different. When used as a destination address, it means what I >> said. How the IP stack/hardware deals with it is dependent on >> the implementation. The RFCs specify that it should be treated >> the same as the broadcast address, but local network only, and >> not routable. That may be for received packets only, as I've >> seen other references that it should never be used on-the-wire, >> unless as the source address in protocols like DHCP. In any >> event, definitely not expect the 0.0.0.0. address to get any >> response, either local host or otherwise. For the OP's specific >> problem, s/he need to see how "localhost" is resolving. Most >> systems define it in the local "hosts" file, either /etc/hosts >> (*nix) or c:\Windows\system32\etc\hosts. Not sure for other >> systems. Jeff > > Make that C:\Windows\system32\drivers\etc\hosts. > > I did a test and it appeared that ping didn't rely on the entry > being there, but it could have been a cached result. Way back in the day when I had the misfortune to use Windows regularly for stuff like this, I seem to recall that almost nothing short of a reboot would cause the "hosts" file to be re-read. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPzeXAAoJEBzwKT+lPKRYDzgP+gJ/DQ320tG26DcGqhjd3xjH l4KRhMdYI0NwxAAhU//FnjdmdG7fjnN7evFy5w2NF6/P+d9aLcj4rANsszc3hwgF fai5E8IHyvSLnVPiUYZoggLCYCzGES9vp15hckWDowGc9xIHCXWJWnftXCeEvfIb DqT8RFIe7u7ENR4gIDh2+C+a/kgg1oTsgm5NXIaR26xDZaimSDbuakV+5XYi7ZJ5 r36SYsjgj+Hfw+VOAsCndHeg0cYAb68KU9YKJCbdQH1oUgJ0sNmr+8nUbsFN1vcT Jy9dSeJUkbk6y9HuEqVAFKyAq2mwHyEwwQanf7NF5FhOKAIXaf3CvcYFjyCvXYGj 7mPzlSgV6QoQ02fR7MQyKDkYdd4eQVl+w8JfQMmXJc1MbYUi9pRzE0dFpTKkSUaG 5b6Vg8dugekBr3LvuPEA3ZztpF5V27mU7zZ0HBIt3ZcKs46qkrjJNgJQwEt688jS UD3ekyK17pDghFvH8d4Br5yQmtrDqdc/gEmyyI1Lny9qoI6Qsouj/PbI0vT5lrB0 mmvLxTBNJLJhMb8jz+0jE800WUXWipL2USU5A1e7Y5LG5klTzSj7JwC7saYyesrj +WRX7RSVzDfrlqLdKmzDwUMlBpNfkhE52x8oZFAveatNizZpTOxDoLXZotCr1UhK mK84Z0r+i6rj8v31TQ/g =v5hD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
