Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <533FFD9B.6020207@ice-sa.com>
Date: Sat, 05 Apr 2014 14:56:59 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
 work
References: <F3A2D2C96F17264D910CB93778C48427568F05FF@ZMBX04.bgr.local>
 <533C2161.9050900@ice-sa.com>
 <F3A2D2C96F17264D910CB93778C48427568F079C@ZMBX04.bgr.local>
 <533D63B2.6020100@ice-sa.com>
 <F3A2D2C96F17264D910CB93778C48427568F07DA@ZMBX04.bgr.local>
 <533DB7AA.5050600@ice-sa.com> <533DD41E.5020504@christopherschultz.net>
 <533DE04E.6060504@ice-sa.com>
 <7215BA462D00D343B2837F9113F0131F0181A33AB3@POSTOFFICE02.polydyne.com>
 <533ECE6D.4070304@christopherschultz.net>
 <7215BA462D00D343B2837F9113F0131F0181A33B08@POSTOFFICE02.polydyne.com>
 <7215BA462D00D343B2837F9113F0131F0181A33B37@POSTOFFICE02.polydyne.com>
In-Reply-To: 
 <7215BA462D00D343B2837F9113F0131F0181A33B37@POSTOFFICE02.polydyne.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Jeffrey Janner wrote:
>> -----Original Message-----
>> From: Jeffrey Janner [mailto:Jeffrey.Janner@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:chris@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:aw@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
> 

Summary of what went on previously :
I did ask before, in the thread, to Jessica to do a "ping localhost" on the Apache/Tomcat 
server where the issue arises. It does ping "127.0.0.1".
I presume that "ping" does resolve the name "localhost" by using the local resolver.
Yet mod_jk's log seems to show that it is trying, as a client, to connect to "0.0.0.0", 
although it's worker's host address is specified as "localhost".
That is what's puzzling us all so far.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org