-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeffrey,
On 4/4/14, 10:50 AM, Jeffrey Janner wrote: >> -----Original Message----- From: André Warnier >> [mailto:a...@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. Jessica-Aileen, can you enable mod_jk's DEBUG logging? It might be instructive to see what it's trying to load when you give it "localhost". I haven't checked the code, but it might tell us what's going on with its name resolution. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPs5tAAoJEBzwKT+lPKRYCvIQAJbXcUMzhL0v/LYvuXCnV1lB I1iRUfeQvcCw9Mi+2U8MVVIGm2UbMk6c/60H/p+ybFDBW0v22IvlIl80FqjzG2ma kS5RMaYtIkIbNSWFI4ijLQMCzahKwBR4UO71F3HVtm2oCTKrOP3Rr490UPSmPTgf EQJjYJtT1zbzfSYPS/B98iLawaRz73iySlswHymUp10ZRmwphgnZukKD8slENXw0 M2Ka5nQfNI60vSKPZ9lsuBtKjpo2FyBaJVRWUN268lVBzLlYdLiGmNCHKqLgS07n q1OQTBFiQEAYqJbh0gRgM6AdOD6+od5uKuM6VGkG4co1pIwmWBzHuMCF/VmrSnfY +9ROZ3WJ1/vB1UF6uuuu6bTGWMS6HdEfjDy3RF5EZt2ibZ4VuuMBQD2iTLSpkspk 00vbjY0K/rcyIu9x3l4mcFSrEFS9aTzugX4Z8RtYA3mwrSvrNUYjcFuTH2kCNZUP 8uG5JQFKzmPK1PU6yiXMV7wPdP2RYeHzM600sJxQ78ZT2kNlmIllppxTlOYn8nQQ zoSn2d8K6MSWPyw8zGwal7RDjEoBBLeeiksw2WXMTd3hVUJ7eBJ04byUci/6TUCw 16vm7pjjtuQxb1EqycZrFYUYUnpuK3yYTITDIhY/gbwP3SZkH132Hb5csWEjCLE5 okPexSaTkOr08dnCLYb8 =l30G -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
