You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Alten, Jessica-Aileen" <Je...@liag-hannover.de> on 2014/04/02 15:23:30 UTC
tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Hi all,
I have a problem with the new release of the tomcat-connector (1.2.39) for
64 Bit Windows (isapi_redirect.dll), binary download.
The older versions worked like a charm under Windows Server 2008 R2 64 Bit
and Windows 7 64 Bit, even in a loadbalancing configuration. But after
switching to the new 1.2.39 version, no connection between IIS and Tomcat
(6.0.39, 7.0.52) can be established.
The isapi_redirect log says:
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed
(errno=49)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (1019): Failed opening socket to
(0.0.0.0:8009) (errno=49)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
ajp_send_request::jk_ajp_common.c (1659): (ajp13w) connecting to backend
failed. Tomcat is probably not started or is listening on the wrong port
(errno=49)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
ajp_service::jk_ajp_common.c (2669): (ajp13w) sending request to tomcat
failed (recoverable), because of error during request sending (attempt=2)
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
ajp_service::jk_ajp_common.c (2689): (ajp13w) connecting to tomcat failed.
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info] service::jk_lb_worker.c
(1514): service failed, worker ajp13w is in error state
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [info] service::jk_lb_worker.c
(1594): All tomcat instances are busy or in error state
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error] service::jk_lb_worker.c
(1599): All tomcat instances failed, no more workers left
[Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
HttpExtensionProc::jk_isapi_plugin.c (2327): service() failed with http
error 503
The worker configuration is:
# workers.properties.minimal -
#
worker.list=wlb,jkstatus
#
worker.ajp13w.type=ajp13
worker.ajp13w.host=localhost
worker.ajp13w.port=8009
#
worker.wlb.type=lb
worker.wlb.balance_workers=ajp13w
#
worker.jkstatus.type=status
#
The configuration is a rudimentary version of the productive system
(concerning "worker.wlb.type=lb"), where three Tomcat instances are running
on a server.
The log file was absolutely clean (only init and terminate messages) before
version 1.2.39 and is clean again after switching back to version 1.2.37,
the connection between IIS and Tomcat is working, port 8009 works with
1.2.37.
In both cases Tomcat is running and listening to the right port. I've
restarted the systems after changing the Dlls.
Can anybody help with this problem?
Thanks in advance,
Jessica
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by "Alten, Jessica-Aileen" <Je...@liag-hannover.de>.
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
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by André Warnier <aw...@ice-sa.com>.
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
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Martin Gainty <mg...@hotmail.com>.
> From: Jeffrey.Janner@PolyDyne.com
> To: users@tomcat.apache.org
> Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
> Date: Fri, 4 Apr 2014 17:33:08 +0000
>
> > -----Original Message-----
> > From: Jeffrey Janner [mailto:Jeffrey.Janner@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.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
> Bad test on my part. I did the above by removing the entry from the hosts file.
> Apparently DNS will still resolve it from the DNS server, but not sure how it decides on the address to send.
> If you change the address in the hosts file and then ping, ping will use the hosts file address, but you'll get your responses from 172.0.0.1. (All tests done without rebooting on Windows.)
MG>you of course mean 127.0.0.1?
MG>why not leave the localhost entry in hosts file?
MG>127.0.0.1 localhost
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Jeffrey Janner [mailto:Jeffrey.Janner@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.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
Bad test on my part. I did the above by removing the entry from the hosts file.
Apparently DNS will still resolve it from the DNS server, but not sure how it decides on the address to send.
If you change the address in the hosts file and then ping, ping will use the hosts file address, but you'll get your responses from 172.0.0.1. (All tests done without rebooting on Windows.)
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: David Kerber [mailto:dckerber@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: dckerber@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Martin Gainty <mg...@hotmail.com>.
> Date: Sat, 5 Apr 2014 06:57:23 -0400
> From: dckerber@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Posted by David Kerber <dc...@verizon.net>.
...
>>>>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
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.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.
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 4/4/14, 1:09 PM, 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPzeXAAoJEBzwKT+lPKRYDzgP+gJ/DQ320tG26DcGqhjd3xjH
l4KRhMdYI0NwxAAhU//FnjdmdG7fjnN7evFy5w2NF6/P+d9aLcj4rANsszc3hwgF
fai5E8IHyvSLnVPiUYZoggLCYCzGES9vp15hckWDowGc9xIHCXWJWnftXCeEvfIb
DqT8RFIe7u7ENR4gIDh2+C+a/kgg1oTsgm5NXIaR26xDZaimSDbuakV+5XYi7ZJ5
r36SYsjgj+Hfw+VOAsCndHeg0cYAb68KU9YKJCbdQH1oUgJ0sNmr+8nUbsFN1vcT
Jy9dSeJUkbk6y9HuEqVAFKyAq2mwHyEwwQanf7NF5FhOKAIXaf3CvcYFjyCvXYGj
7mPzlSgV6QoQ02fR7MQyKDkYdd4eQVl+w8JfQMmXJc1MbYUi9pRzE0dFpTKkSUaG
5b6Vg8dugekBr3LvuPEA3ZztpF5V27mU7zZ0HBIt3ZcKs46qkrjJNgJQwEt688jS
UD3ekyK17pDghFvH8d4Br5yQmtrDqdc/gEmyyI1Lny9qoI6Qsouj/PbI0vT5lrB0
mmvLxTBNJLJhMb8jz+0jE800WUXWipL2USU5A1e7Y5LG5klTzSj7JwC7saYyesrj
+WRX7RSVzDfrlqLdKmzDwUMlBpNfkhE52x8oZFAveatNizZpTOxDoLXZotCr1UhK
mK84Z0r+i6rj8v31TQ/g
=v5hD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----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
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----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
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.
Jessica-Aileen, can you enable mod_jk's DEBUG logging? It might be
instructive to see what it's trying to load when you give it
"localhost". I haven't checked the code, but it might tell us what's
going on with its name resolution.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPs5tAAoJEBzwKT+lPKRYCvIQAJbXcUMzhL0v/LYvuXCnV1lB
I1iRUfeQvcCw9Mi+2U8MVVIGm2UbMk6c/60H/p+ybFDBW0v22IvlIl80FqjzG2ma
kS5RMaYtIkIbNSWFI4ijLQMCzahKwBR4UO71F3HVtm2oCTKrOP3Rr490UPSmPTgf
EQJjYJtT1zbzfSYPS/B98iLawaRz73iySlswHymUp10ZRmwphgnZukKD8slENXw0
M2Ka5nQfNI60vSKPZ9lsuBtKjpo2FyBaJVRWUN268lVBzLlYdLiGmNCHKqLgS07n
q1OQTBFiQEAYqJbh0gRgM6AdOD6+od5uKuM6VGkG4co1pIwmWBzHuMCF/VmrSnfY
+9ROZ3WJ1/vB1UF6uuuu6bTGWMS6HdEfjDy3RF5EZt2ibZ4VuuMBQD2iTLSpkspk
00vbjY0K/rcyIu9x3l4mcFSrEFS9aTzugX4Z8RtYA3mwrSvrNUYjcFuTH2kCNZUP
8uG5JQFKzmPK1PU6yiXMV7wPdP2RYeHzM600sJxQ78ZT2kNlmIllppxTlOYn8nQQ
zoSn2d8K6MSWPyw8zGwal7RDjEoBBLeeiksw2WXMTd3hVUJ7eBJ04byUci/6TUCw
16vm7pjjtuQxb1EqycZrFYUYUnpuK3yYTITDIhY/gbwP3SZkH132Hb5csWEjCLE5
okPexSaTkOr08dnCLYb8
=l30G
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
not work
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, April 04, 2014 10:20 AM
> To: Tomcat Users List
> Subject: Re: [OT] 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:
> > I've not followed the complete thread, but if the server is a *nix
> > implementation, the better diag tool might be dig.
>
> No, you haven't been following it well. The subject pretty much rules-
> out a *NIX environment ;)
>
Touché
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
not work
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
> I've not followed the complete thread, but if the server is a *nix
> implementation, the better diag tool might be dig.
No, you haven't been following it well. The subject pretty much
rules-out a *NIX environment ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPs2OAAoJEBzwKT+lPKRYtFUP/i80QgR+0ZrDjsn7sCceJ5yn
uksnWkLAsWtpNn8hVPe7t2dHrwyAIDiz32PhEy493EKniCjnvuF74lfHuLpCfYax
n8Ju57djYTuEEI5+R1MYDsacJlnG0f8KKgA8RIAl8wFKED0O7D6wzA5bNj0mh6eO
Bqa04hTKEX5XfEaBdX6czhmgZjc+fBCw6l3nSG/+S1meFzxCggluAgceU7HdPlRG
gvjTJz/qRrfNdWTcZMry7ryFS2vYp5A7QloYV1nE6a9Ujw6s1k6sLkCBR8lfCMum
9ossRGkDdlRvJcaCZkLB7W/Cur+zzYwCw87F5OqQGP6fmaZgA1QmENy4KeXTNx6Y
2CmhDEh0U64NVGqjM/zhNX0MfVv70rOGOa6PcUJ/VkEwNRfEoaSHSURX39pPoTkG
v3xlA+TrTfQ+0kdYtUsz6bhrkrZWwLsrn39S3qrpPI+1KIzED+ejcEm0DIiCXl8B
e+ZplZv7jDLoP0GCqu+KwJMrx81bJk8KGQli5HgnFJAa/S8oR8UXLVS2GXHIg4bb
Rb8ucmW6DBT/ugJZ96sCktEZTrlPe8Ds2ho8OZvQFLrOXxUkKqo3eNzRtEiBDWF7
e9Lz8OkJXdyYh3GrsucUQYnjmlh2OkpEUiZnZaHKLTDrP4ILk3/FcxrVOfyTwKQl
/294/H1UfXoAKDbwYBwg
=F5eV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----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.
Jeff
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by André Warnier <aw...@ice-sa.com>.
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-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 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.)
Mmmm.
If only by curiosity, maybe Jessica-Aileen could try
worker.ajp13w.host=localhost.
(ending in dot)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-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 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?).
- -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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-04-03 23:34 GMT+04:00 André Warnier <aw...@ice-sa.com>:
> 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-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 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
>
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
work
Posted by André Warnier <aw...@ice-sa.com>.
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-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 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
Rainer ? Mladen ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Posted by "Alten, Jessica-Aileen" <Je...@liag-hannover.de>.
> -----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-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 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
Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Posted by André Warnier <aw...@ice-sa.com>.
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 :
Note : I would be really surprised if mod_jk did not parse this correctly.
More likely is, that "localhost" on that system, is aliased to some invalid target IP address.
IP address 0.0.0.0, for a "listen" socket, means "any configured IP address of this
computer". But for a client socket, connecting to "0.0.0.0" does not really make sense.
In your case, the AJP connector in Tomcat is the server, and it listens to 0.0.0.0:8009,
and that makes sense as "all interfaces, port 8009".
And mod_jk/isapi is the client in this case. It is trying to connect to "localhost",
which should be 127.0.0.1, under IPv4. That connection would be seen and accepted by the
AJP listening socket.
But mod_jk is probably trying to connect to something else, and failing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Posted by "Alten, Jessica-Aileen" <Je...@liag-hannover.de>.
> 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.
Regards,
Jessica
Re: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Posted by André Warnier <aw...@ice-sa.com>.
Alten, Jessica-Aileen wrote:
> Hi all,
>
> I have a problem with the new release of the tomcat-connector (1.2.39) for
> 64 Bit Windows (isapi_redirect.dll), binary download.
> The older versions worked like a charm under Windows Server 2008 R2 64 Bit
> and Windows 7 64 Bit, even in a loadbalancing configuration. But after
> switching to the new 1.2.39 version, no connection between IIS and Tomcat
> (6.0.39, 7.0.52) can be established.
>
> The isapi_redirect log says:
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
> jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed
> (errno=49)
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
> ajp_connect_to_endpoint::jk_ajp_common.c (1019): Failed opening socket to
> (0.0.0.0:8009) (errno=49)
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
> ajp_send_request::jk_ajp_common.c (1659): (ajp13w) connecting to backend
> failed. Tomcat is probably not started or is listening on the wrong port
> (errno=49)
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [info]
> ajp_service::jk_ajp_common.c (2669): (ajp13w) sending request to tomcat
> failed (recoverable), because of error during request sending (attempt=2)
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
> ajp_service::jk_ajp_common.c (2689): (ajp13w) connecting to tomcat failed.
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [info] service::jk_lb_worker.c
> (1514): service failed, worker ajp13w is in error state
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [info] service::jk_lb_worker.c
> (1594): All tomcat instances are busy or in error state
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [error] service::jk_lb_worker.c
> (1599): All tomcat instances failed, no more workers left
> [Wed Apr 02 13:23:36.319 2014] [5676:2148] [error]
> HttpExtensionProc::jk_isapi_plugin.c (2327): service() failed with http
> error 503
>
>
> The worker configuration is:
> # workers.properties.minimal -
> #
> worker.list=wlb,jkstatus
> #
> worker.ajp13w.type=ajp13
> worker.ajp13w.host=localhost
> worker.ajp13w.port=8009
> #
> worker.wlb.type=lb
> worker.wlb.balance_workers=ajp13w
> #
> worker.jkstatus.type=status
> #
>
> The configuration is a rudimentary version of the productive system
> (concerning "worker.wlb.type=lb"), where three Tomcat instances are running
> on a server.
>
> The log file was absolutely clean (only init and terminate messages) before
> version 1.2.39 and is clean again after switching back to version 1.2.37,
> the connection between IIS and Tomcat is working, port 8009 works with
> 1.2.37.
> In both cases Tomcat is running and listening to the right port. I've
> restarted the systems after changing the Dlls.
>
> Can anybody help with this problem?
>
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" ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org