> From: jeffrey.jan...@polydyne.com
> To: users@tomcat.apache.org
> Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
> Date: Fri, 4 Apr 2014 17:33:08 +0000
>
> > -----Original Message-----
> > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> > Sent: Friday, April 04, 2014 12:10 PM
> > To: 'Tomcat Users List'
> > Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
> > not work
> >
> > > -----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.
> > Jeff
> Bad test on my part. I did the above by removing the entry from the hosts
> file.
> Apparently DNS will still resolve it from the DNS server, but not sure how it
> decides on the address to send.
> If you change the address in the hosts file and then ping, ping will use the
> hosts file address, but you'll get your responses from 172.0.0.1. (All tests
> done without rebooting on Windows.)
MG>you of course mean 127.0.0.1?
MG>why not leave the localhost entry in hosts file?
MG>127.0.0.1 localhost
