RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Hi all, the new tomcat-connectors-1.2.40-windows-x86_64-iis works with the localhost setting in workers.properties! Great! Many thanks to the developers! :-) Regards, Jessica smime.p7s Description: S/MIME cryptographic signature
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
On 04/15/2014 02:58 PM, Alten, Jessica-Aileen wrote: Hi all, the new tomcat-connectors-1.2.40-windows-x86_64-iis works with the localhost setting in workers.properties! Great! Many thanks to the developers! :-) You're welcome. Thanks for filing the bug and confirming the fix. It was that kind of bug that does not show on all boxes and all the time. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Sorry, I don't know how Windows internally resolves localhost. What I
wanted to say is, that the hosts file has not been modified on that
system - by default it does not contain any entries. This seems to have
changed since some Windows versions, as e.g. Windows Vista contains
127.0.0.1 localhost and ::1 localhost by default
in its hosts file, but starting with Windows 7, the hosts file only
contains comments by default, with the hint localhost name resolution
is handled within DNS itself.
I just wrote a small C# program to see how .Net resolves localhost:
private static void Main(string[] args) {
IPAddress[] addresses = Dns.GetHostAddresses(localhost);
foreach (IPAddress a in addresses) {
Console.WriteLine(a.ToString());
}
Console.ReadKey();
}
When I run it on the server machine, it prints the normal IPv4 and IPv6
loopback addresses:
::1
127.0.0.1
Perhaps this might be the reason why it doesn't work in my case - on our
servers and workstations ipv6 is disabled, the registry setting is
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters]
DisabledComponents=dword:00ff
See the discussion on
http://social.technet.microsoft.com/Forums/en-US/d7bfc3f0-1ea7-43e9-aaae-7b1d5c0b5c51/how-to-disable-ipv6-in-registry?forum=windowsserver2008r2networking
about ff and
I'll try to check my settings with the C# program.
Regards,
Jessica
smime.p7s
Description: S/MIME cryptographic signature
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
I'll try to check my settings with the C# program. Ipv6 loopback is available: 127.0.0.1 ::1 See http://support.microsoft.com/kb/929852 However, I believe the disabled ipv6 might put us on the right track. Regards, Jessica smime.p7s Description: S/MIME cryptographic signature
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Alten, Jessica-Aileen wrote: I'll try to check my settings with the C# program. Ipv6 loopback is available: 127.0.0.1 ::1 See http://support.microsoft.com/kb/929852 However, I believe the disabled ipv6 might put us on the right track. Anyway, Konstantin filed an issue in Bugzilla for this a few days ago already, it looks like there may indeed be a problem in the code, and the issue is being looked at. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=56352 This looks like it may be tied to the absence of a line 127.0.0.1 localhost in the local system's hosts file ((windows)/system32/drivers/etc/hosts) So it would probably help if one of the Windows experts on this list confirmed that, by default, since version xyz of Windows, there is no longer such an entry in the hosts file. My (about to become unsupported but venerable) Windows XP laptop does have a localhost line. On the other hand, a Windows 7 workstation to which I have access has this in the hosts file : # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost note@jessica : It may be interesting to see what happens if you add a line like this in the server's hosts file : 127.0.0.1 localhost localtomcat and then try to use each of these names in your isapi configuration for the worker.host. (for a personal definition of interesting) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
It may be interesting to see what happens if you add a line like this in the server's hosts file : 127.0.0.1 localhost localtomcat and then try to use each of these names in your isapi configuration for the worker.host. I tried the formerly commented out lines in the hosts file after a reboot: 127.0.0.1 localhost ::1 localhost Unfortunately this doesn't work either: localhost doesn't work in the workers.properties file. The error log is the same as the previous one. Regards, Jessica smime.p7s Description: S/MIME cryptographic signature
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Alten, Jessica-Aileen wrote: It may be interesting to see what happens if you add a line like this in the server's hosts file : 127.0.0.1 localhost localtomcat and then try to use each of these names in your isapi configuration for the worker.host. I tried the formerly commented out lines in the hosts file after a reboot: 127.0.0.1 localhost ::1 localhost Unfortunately this doesn't work either: localhost doesn't work in the workers.properties file. The error log is the same as the previous one. Hi. Ok, there is apparently a bug in the isapi-redirector, and the developers are working on it. What I am trying to do, is to see if there is not some alternative in-between solution for you, other than using worker.ajp13w.host=127.0.0.1 (which is kind of not elegant) What you did above (uncommenting *both* lines), still leaves the possibility that isapi would be trying to use the ::1 IPv6 translation, and hitting a problem due to IPv6 being disabled on that system. To eliminate that, could you try precisely the following : 1) re-comment the 2 lines in the hosts file 2) add this line : 127.0.0.1 localtomcat 3) in your properties file : worker.ajp13w.host=localtomcat Note that this is basically intellectual curiosity on my part. You can also decide to wait for the bug correction. I would try this myself to assuage my curiosity, but I do not have an advanced enough Windows server at my disposal right now. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Hi all, I'm stunned about the enormous response to my question and I'm so sorry about the long delay of my answer now - but there is a world outside with household chores at the weekend. I'll try to answer the questions from the oldest to the youngest: 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 ?) Definitively ;-) I stumbled on this problem on a server (Windows Server 2008 R2), then tried it on my workstation (Windows 7) which has the same configuration for Tomcat and IIS (and and where it doesn't work either). On the server I had no logfile. test : 1) telnet localhost 8009 2) telnet 127.0.0.1 8009 With worker.ajp13w.host=localhost 1) No answer (windows telnet: black console; cygwin telnet: no action, new prompt) 2) No answer (windows telnet: black console; cygwin telnet: no action, new prompt) With worker.ajp13w.host=127.0.0.1 1) No answer (windows telnet: black console; cygwin telnet: no action, new prompt) 2) No answer (windows telnet: black console; cygwin telnet: no action, new prompt) telnet doesn't work at all, no connection to any server on the local pc, in the intranet or internet (perhaps a firewall/proxy/ntlm setting). Could this be an interaction between IPv4 and IPv6? Try: C: nslookup localhost nslookup localhost Server: dns.xyz.local Address: a.b.c.d Non-authoritative answer: Name:localhost.domainname.local Address: 127.0.0.1 If only by curiosity, maybe Jessica-Aileen could try worker.ajp13w.host=localhost. That doesn't make a difference. It doesn't work. 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. See attachment. By the way: The description of prefer_ipv6 is unclear. I used worker.ajp13w.prefer_ipv6=0, but the omission doesn't make a difference. It doesn't work either. For the OP's specific problem, she 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. There is _no_ _entry_ in the hosts file, it is commented out - which is the _default_ for Windows! See http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost Regards, Jessica isapi_redirect.log Description: Binary data smime.p7s Description: S/MIME cryptographic signature
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-Original Message- From: David Kerber [mailto:dcker...@verizon.net] Sent: Saturday, April 05, 2014 5:57 AM To: Tomcat Users List Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work ... 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. ipconfig /flushdns From empirical testing over the years, I'm pretty sure that Microsoft implements multiple levels of DNS caching. I'm positive that the IE browser will cache some information on its own. I've had DNS failures that would not resolve at the browser level after being fixed until I restarted the browser. I could resolve with nslookup, ping, etc., but the browser would still report an error. Even the ipconfig /flushdns would not fix it for IE. If only the kids at MS would do things the correct and consistent way, life would be easier for all of us. On my previously referenced test, I modified the hosts table to use 127.0.0.10 for the localhost entry. Ping picked it up right away, but reported results were from 127.0.0.1, which I'm sure was probably because of the initialized value pulled from the hosts table at boot. Did not try, do not care, but it might have replied from the 10 address after a reboot. Note, I did not expect to see a change on an nslookup, since that tool is designed to query the DNS servers directly, bypassing the resolver. It's a test tool for the DNS system, not the resolver sub-system. This has gotten way of topic, so last word on my part. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Hi, -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Monday, April 7, 2014 5:46 PM (...) On my previously referenced test, I modified the hosts table to use 127.0.0.10 for the localhost entry. Ping picked it up right away, but reported results were from 127.0.0.1, which I'm sure was probably because of the initialized value pulled from the hosts table at boot. Did not try, do not care, but it might have replied from the 10 address after a reboot. That is because it seems any address from 127.0.0.1 to 127.255.255.254 may be used as loopback address - see [1]. E.g. if you ping 127.2.3.4, you will get the same results as with 127.0.0.1. It would have surprised me if ping would report the results for a wrong IP address. As for the topic, I cannot help much, but I wanted to note that I'm also using the ISAPI Connector 1.2.39 (x64) on a Windows Server 2012 R2, but I did not encounter the reported issue. This is my workers.properties: # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8019 On that system, Tomcat listens on both [::]:8019 and 0.0.0.0:8019, and the ISAPI connector uses 127.0.0.1:8019 to connect to Tomcat. The hosts file on this system doesn't contain any entry. Regards, Konstantin Preißer [1] http://superuser.com/questions/393700/what-is-127-0-0-2-ip-address-for - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
From: Konstantin Preißer [mailto:kpreis...@apache.org] Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work I wanted to note that I'm also using the ISAPI Connector 1.2.39 (x64) on a Windows Server 2012 R2, but I did not encounter the reported issue. This is my workers.properties: # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8019 On that system, Tomcat listens on both [::]:8019 and 0.0.0.0:8019, and the ISAPI connector uses 127.0.0.1:8019 to connect to Tomcat. The hosts file on this system doesn't contain any entry. Any theories on how localhost gets resolved on your system? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Hi Chuck,
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Monday, April 7, 2014 7:06 PM
To: Tomcat Users List
Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
not work
From: Konstantin Preißer [mailto:kpreis...@apache.org]
Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
not work
I wanted to note that I'm also using the ISAPI Connector 1.2.39 (x64)
on a Windows Server 2012 R2, but I did not encounter the reported issue.
This is my workers.properties:
# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8019
On that system, Tomcat listens on both [::]:8019 and 0.0.0.0:8019, and
the ISAPI connector uses 127.0.0.1:8019 to connect to Tomcat. The hosts
file on this system doesn't contain any entry.
Any theories on how localhost gets resolved on your system?
Sorry, I don't know how Windows internally resolves localhost. What I wanted
to say is, that the hosts file has not been modified on that system - by
default it does not contain any entries. This seems to have changed since some
Windows versions, as e.g. Windows Vista contains 127.0.0.1 localhost
and ::1 localhost by default in its hosts file, but starting
with Windows 7, the hosts file only contains comments by default, with the hint
localhost name resolution is handled within DNS itself.
I just wrote a small C# program to see how .Net resolves localhost:
private static void Main(string[] args) {
IPAddress[] addresses = Dns.GetHostAddresses(localhost);
foreach (IPAddress a in addresses) {
Console.WriteLine(a.ToString());
}
Console.ReadKey();
}
When I run it on the server machine, it prints the normal IPv4 and IPv6
loopback addresses:
::1
127.0.0.1
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
... 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. ipconfig /flushdns - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Date: Sat, 5 Apr 2014 06:57:23 -0400 From: dcker...@verizon.net To: users@tomcat.apache.org Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work ... 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. ipconfig /flushdns MG ipconfig/flushdns *should* flush the ips and the dns entries to test use a browser that doesnt cache dns entries (like firefox) go to address bar about:config network.dnsCacheExpirationGracePeriod http://kb.mozillazine.org/Network.dnsCacheExpiration hth, Martin MG - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup 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
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
2014-04-03 23:34 GMT+04:00 André Warnier a...@ice-sa.com: 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-between- 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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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 Rainer ? Mladen ? After some code review, I think there is a bug there. I filed an issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=56352 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 4/5/14, 8:35 AM, Martin Gainty wrote: Date: Sat, 5 Apr 2014 06:57:23 -0400 From: dcker...@verizon.net To: users@tomcat.apache.org Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work ... 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. ipconfig /flushdns MG ipconfig/flushdns *should* flush the ips and the dns entries to test use a browser that doesnt cache dns entries (like firefox) Firefox sure does cache DNS entries. Just Google for firefox dns cache and you'll find many recipes for flushing the cache. go to address bar about:config network.dnsCacheExpirationGracePeriod http://kb.mozillazine.org/Network.dnsCacheExpiration You just gave instructions to alter Firefox's DNS cache. (!!) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTQD3AAAoJEBzwKT+lPKRYpR0P/jp9BUFs5BasKJZIkGHoj1bA T1ACjBJYxSEzBKxZPFMKh+UQhNl00FitoSnjzB4YWHT2A814S0P/6DVFn8+dh6Qe CYqEFD2L6xhwMfqPcysEU9K2UtdFV/E5uSqS2pysNb399YIA4dagRYCy92YcBH9K HFLKvbJ/wwM7GqaHfvqeoSUJ4aJUGF08pnwBPwW+3tpM9jYu5qZelgAsGQrhJ2uS jWok1Zcvl1qbXOciNTb6DKJklwLoI5hsp5C7Y7LdRV3Ner9nZ/zWuaVfGPrXL+XW +lfbo0S10datHBJl5afFOcusvFSU7cHmhBljkK1QfzAg4OyYt+OpNRFCWFoy1KSU yVgVcEcKy3TH5P+lmN5NCvXv3J9TKB5eOqLL/Kws6TVj+sLMb8pJTGum/Nzs2es3 i+//gBQLS9sQVF42HEC+QDc4Vp1346ICsTpYku1Tv+NeexG7xZyHDmAgBjF7IfnV s2ihdQ0quT9gK6RyGYyNNcm5k8NCJwYgWiytmz0dBq2Kr+s2P4r9+hI8n6QU5c7F Fm4MgsI48SgP9M8Pv4MMtJ5/GOKvLUzX3/bT4N9M9JW4tudelhYyGJ0M1bY6VBw0 yLlNtfLTbB4G9G0YNsnMEDQ+IptHm1G5bM+sUzAeUfuDshaKTOygPWC1fCb5DUNd /Eilbqa1uw/wtEvXLBeM =LsAW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup 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
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: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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup 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
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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup 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
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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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
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: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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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
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, 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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup localhost. Server: fire-see.localdomain Address
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
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 + -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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup localhost. Server: fire-see.localdomain Address: 192.168.245.253 Name:localhost Address: 127.0.0.1 (But that of course could
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
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-between- 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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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 Rainer ? Mladen ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-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-between- 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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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?). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPdQeAAoJEBzwKT+lPKRY6i4P/jv+ozeg+saTWEDwWeR769JQ 1d3Y3n9Cnvk5qHlvEkTxOzu72MdUtl3+eLLgCT+7QNRQWr3m/Lj+vlN8E+M0d/6X BWs8/XDP3fMyc6eBgQiTQWTZUMH1sGua4ceJ24PLviK1Pq9jambFeHHvdYluDK4K ItgDyfXf9GkO5SsMvQxcic2VpjPxkPwM6W3ndjvDGYAucwK3ZW5FQTZ0GAsmvYac 6jGa7UJWCJA0VemInPIR0J5wlOpDq+GtjKTBaGltAbgVew7U91uuCyB9ll9Ybrug buETKMaB/o+P57e3atUoWRz5/pUAaZJDE75HDguKS+z2Io5SXR7zOynOhqso89em kTZ5UvpuO8ffeqqTn9WK7y8roGcYP+PBDdmBgbZF3RysFw+sLaWaRP08rPHMPe7X Yiw0pZbxSAEwlBcPiPrueqjHxiC1jtGFfpFqaywrNfAkDKSWl/ckzenAZzRlwimS G0cpbLxGPnvQaqf58jvkntd102tGSMgb7mhVTNDsCu0+IFRfuN+iFy76LpgMwcYc dZUL5r23gj5Vqe5f9k9GdI8sF6XLPf7juoUXJKRIer9wLhNvTeriv0jCnWhk7SqQ ysHmtssDzV6jAF9fsGGWrtYTD/LE9NY+WTSDAMv+hZTn/OQZRUPGZ4XS3UN1HE1P 1OWrGlm0IGcgZFzqPRTA =JW/W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-between- 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 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms 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\awnslookup 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\awnslookup 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.) Mmmm. If only by curiosity, maybe Jessica-Aileen could try worker.ajp13w.host=localhost. (ending in dot) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
