On 4/4/2014 5:52 PM, Christopher Schultz wrote:
-----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
If I remember correctly, the Windows resolver cache may be cleared from
a command prompt with ipconfig and that should include entries from the
hosts file. Seems like I may have had to restart the browser though to
see any changes to the hosts file.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
