Re: [OT] timeout
On Sat, Apr 5, 2014 at 8:35 AM, Vicky B wrote: > The problem is solved now . Erm, well. Perhaps for some definition of "solved"... > I had no clue that firewall would drop the connection if it does not > recieve response within stiplulated time. > Can i increase this timeout period ? May I suggest Reading The Fine Manual for your particular firewall would be preferable to asking random non-psychic strangers? > if firewall was not there then my app would i worked properly ? Maybe, maybe not; turn it off and see what happens. Or set up a test environment without one and compare. -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 4/5/14, 8:35 AM, Martin Gainty wrote: > > > >> Date: Sat, 5 Apr 2014 06:57:23 -0400 From: dcker...@verizon.net >> To: users@tomcat.apache.org Subject: Re: AW: AW: >> tomcat-connectors-1.2.39-windows-x86_64-iis does not work >> >> ... >> >>> but if the server is a *nix implementation, the better diag tool might be dig. And yes, I would not expect the address 0.0.0.0 on a client to connect to the localhost. That is a special case address >> meaning "local network". If anything, it would be sending packets out the NIC card, not via loopback. >>> 0.0.0.0 means "all IPv4 interfaces available" and only >>> applies for binding a server socket. You can never >>> connect to "0.0.0.0" as a client. >>> >> Chris - It actually has a different meaning based on use. >> For binding to a socket in the local IP stack, it means >> what you say. In the routing table, it means the default >> route. In firewalls/routers, it probably means something >> completely different. When used as a destination address, >> it means what I said. How the IP stack/hardware deals >> with it is dependent on the implementation. The RFCs >> specify that it should be treated the same as the >> broadcast address, but local network only, and not >> routable. That may be for received packets only, as I've >> seen other references that it should never be used >> on-the-wire, unless as the source address in protocols >> like DHCP. In any event, definitely not expect the >> 0.0.0.0. address to get any response, either local host >> or otherwise. For the OP's specific problem, s/he need to >> see how "localhost" is resolving. Most systems define it >> in the local "hosts" file, either /etc/hosts (*nix) or >> c:\Windows\system32\etc\hosts. Not sure for other >> systems. Jeff > Make that C:\Windows\system32\drivers\etc\hosts. > > I did a test and it appeared that ping didn't rely on the > entry being there, but it could have been a cached result. Way back in the day when I had the misfortune to use Windows regularly for stuff like this, I seem to recall that almost nothing short of a reboot would cause the "hosts" file to be re-read. - -chris >>> >>> >>> If I remember correctly, the Windows resolver cache may be >>> cleared from a command prompt with ipconfig and that should >>> include entries from the hosts file. Seems like I may have had >>> to restart the browser though to see any changes to the hosts >>> file. >> >> ipconfig /flushdns > > MG> ipconfig/flushdns *should* flush the ips and the dns entries to > test use a browser that doesnt cache dns entries (like firefox) Firefox sure does cache DNS entries. Just Google for "firefox dns cache" and you'll find many recipes for flushing the cache. > go to address bar > > about:config network.dnsCacheExpirationGracePeriod > > http://kb.mozillazine.org/Network.dnsCacheExpiration You just gave instructions to alter Firefox's DNS cache. (!!) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTQD3AAAoJEBzwKT+lPKRYpR0P/jp9BUFs5BasKJZIkGHoj1bA T1ACjBJYxSEzBKxZPFMKh+UQhNl00FitoSnjzB4YWHT2A814S0P/6DVFn8+dh6Qe CYqEFD2L6xhwMfqPcysEU9K2UtdFV/E5uSqS2pysNb399YIA4dagRYCy92YcBH9K HFLKvbJ/wwM7GqaHfvqeoSUJ4aJUGF08pnwBPwW+3tpM9jYu5qZelgAsGQrhJ2uS jWok1Zcvl1qbXOciNTb6DKJklwLoI5hsp5C7Y7LdRV3Ner9nZ/zWuaVfGPrXL+XW +lfbo0S10datHBJl5afFOcusvFSU7cHmhBljkK1QfzAg4OyYt+OpNRFCWFoy1KSU yVgVcEcKy3TH5P+lmN5NCvXv3J9TKB5eOqLL/Kws6TVj+sLMb8pJTGum/Nzs2es3 i+//gBQLS9sQVF42HEC+QDc4Vp1346ICsTpYku1Tv+NeexG7xZyHDmAgBjF7IfnV s2ihdQ0quT9gK6RyGYyNNcm5k8NCJwYgWiytmz0dBq2Kr+s2P4r9+hI8n6QU5c7F Fm4MgsI48SgP9M8Pv4MMtJ5/GOKvLUzX3/bT4N9M9JW4tudelhYyGJ0M1bY6VBw0 yLlNtfLTbB4G9G0YNsnMEDQ+IptHm1G5bM+sUzAeUfuDshaKTOygPWC1fCb5DUNd /Eilbqa1uw/wtEvXLBeM =LsAW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] timeout
HI All, The problem is solved now . we are have implemented a callback functionality where after every 45 seconds we call back the same method again .Hence making sure that there is no timeout. But as per identifying the actual reason behind the problem i tried to reproduce the issue,after every time after response exceeds 1 min i would get same internal error with same logs as I had mentioned earlier .I got the confirmation that there is firewall between users browser and web-server but i could not get more information about firewall . I have read many blogs where people have faced same issue because of firewall. I had no clue that firewall would drop the connection if it does not recieve response within stiplulated time. Can i increase this timeout period ? if firewall was not there then my app would i worked properly ? On Mon, Mar 31, 2014 at 8:29 PM, Mark Eggers wrote: > On 3/31/2014 4:18 AM, Vicky B wrote: > >> there is a firewall between browser and apache httpd and i am not sure if >> there is a firewall between apache and tomcat (mostly no). >> > > Mostly? Mostly? As in sometimes there's a firewall, and other times > there's not, but mostly not? > > Or do you mean that you're supporting this application at multiple sites, > and it's misbehaving at some sites? And that most of the sites do not have > a firewall between Apache HTTPD and Apache Tomcat, but some do? > > Or do you mean that you're almost certain that there is no firewall > between Apache HTTPD and Apache Tomcat, but you're not 100% certain? > > > But why would this firewall drop the connection ? >> >> > Firewalls can be configured to drop connections after a certain amount of > inactivity. If you have a long-running process and are not sending > information back to the user, there are many places where the connection > could be closed. > > 1. Between Apache Tomcat and Apache HTTPD > > As I mentioned earlier, if you have configured an AJP timeout (which is > not the default configuration) and it is too short, Apache HTTPD will close > the connection and send an error message back to the browser. > > 2. Firewall between Apache Tomcat and Apache HTTPD > > A firewall can be configured to close connections after a period of > inactivity. > > 3. Firewall between Apache HTTPD and the browser > > A firewall can be configured to close connections after a period of > inactivity. This might generate the type of error in the log extract that > you posted earlier. > > However, that error may be completely unrelated to the problem, as well as > all of these other musings many of us are doing. > > The short answer is that none of us know, because you have not provided > enough information for us to be anything more than speculative. > > If you want help in resolving this problem, you need to provide us with > answers to the questions we've asked (as a start). We can then help (mostly > by asking more questions) narrow down the possibilities, and then possibly > help you solve the problem. > > Or as André politely pointed out, give you enough information so that you > can go back to the developers so that they can fix the problem. As he has > pointed out, 90% of the time it's an application issue. > > There is no 'magic' one line answer and configuration that will fix your > problem (most likely - but again, we don't know). > > If you do not have the answers to the questions we are asking, please go > ask someone who does have the answers and the access for the information. > > Otherwise we're all just wasting time and bandwidth. Meanwhile your users > are still getting errors . . . > > . . . just my (not caffeinated) two cents > /mde/ > > PS - please, please, please do not top-post. Your comments when they're > read first make no sense until you scroll to the bottom and read the rest > of the message. > > /mde/ > > > >> On Mon, Mar 31, 2014 at 3:16 PM, Howard W. Smith, Jr. < >> smithh032...@gmail.com> wrote: >> >> On Mar 31, 2014 3:48 AM, "André Warnier" wrote: >>> Howard W. Smith, Jr. wrote: > > On Sun, Mar 30, 2014 at 9:54 PM, Caldarale, Charles R < > chuck.caldar...@unisys.com> wrote: > > From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] >>> Subject: Re: timeout >>> - and if that is not the reason, then find the person responsible for >>> >> the >> >>> in-between equipment and ask them why their junk closes the >>> connection >>> before your application has a chance to respond >>> >>> 'junk'? please clarify the usage of the word 'junk', here. :) >>> >> >> I think the definition "something of poor quality" would fit in this >> > case, >>> if the poor quality were a result of configuring equipment without >> > regard >>> to the requirements of the network users. >> >> - Chuck >> >> > understood, thanks Chuck. :) > >
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
2014-04-03 23:34 GMT+04:00 André Warnier : > Alten, Jessica-Aileen wrote: >>> >>> -Ursprüngliche Nachricht- >>> Von: André Warnier [mailto:a...@ice-sa.com] >>> Gesendet: Donnerstag, 3. April 2014 15:36 >>> An: Tomcat Users List >>> Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not >>> work >>> >>> Alten, Jessica-Aileen wrote: > > A bit guessing here : > > You have : > > worker.ajp13w.host=localhost > > and > > > jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 >>> >>> failed >> >> (errno=49) > > is "localhost" == 0.0.0.0 ? > > From the point of view of mod_jk/isapi, should it not be >>> >>> "127.0.0.1" ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference-between- >>> >>> ip -addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable >>> >>> address. The problem is: The new Tomcat-Connector can't parse "worker.ajp13w.host=localhost", instead localhost must be replaced with "127.0.0.1", this works! In my eyes this is a big fat bug, because most documentation on workers use "localhost". localhost is actually the default for the "host" connection directive. The new worker directive "prefer_ipv6" doesn't change this behavior. >>> Hi. >>> >>> Can you please really check this ? >>> >>> Open a command window on that server, and do "ping localhost". >>> It should tell you what it understands by "localhost". >>> Copy and paste the result here : >> >> >> ping localhost >> >> Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten: >> Antwort von 127.0.0.1: Bytes=32 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
Jeffrey Janner wrote: -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Friday, April 04, 2014 12:04 PM To: 'Tomcat Users List' Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, April 04, 2014 10:23 AM To: Tomcat Users List Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/4/14, 10:50 AM, Jeffrey Janner wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Thursday, April 03, 2014 5:27 PM To: Tomcat Users List Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/3/14, 3:34 PM, André Warnier wrote: Alten, Jessica-Aileen wrote: -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014 15:36 An: Tomcat Users List Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work Alten, Jessica-Aileen wrote: A bit guessing here : You have : worker.ajp13w.host=localhost and jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49) is "localhost" == 0.0.0.0 ? From the point of view of mod_jk/isapi, should it not be "127.0.0.1" ? Your answer points to the right direction. 0.0.0.0 means: any configured IPv4-Address on this computer, see http://serverfault.com/questions/78048/whats-the-difference- betwee n- ip -addre ss-0-0-0-0-and-127-0-0-1 In principle this is ok at first. The Ajp13 Connector was configured in server.xml to listen at any IPv4 address on port 8009 - which is the default setting. But the connector can't find any suitable address. The problem is: The new Tomcat-Connector can't parse "worker.ajp13w.host=localhost", instead localhost must be replaced with "127.0.0.1", this works! In my eyes this is a big fat bug, because most documentation on workers use "localhost". localhost is actually the default for the "host" connection directive. The new worker directive "prefer_ipv6" doesn't change this behavior. Hi. Can you please really check this ? Open a command window on that server, and do "ping localhost". It should tell you what it understands by "localhost". Copy and paste the result here : ping localhost Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 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 nam
RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
> Date: Sat, 5 Apr 2014 06:57:23 -0400 > From: dcker...@verizon.net > To: users@tomcat.apache.org > Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work > > ... > > > but > >> if the server is a *nix implementation, the better diag tool > >> might be dig. And yes, I would not expect the address 0.0.0.0 > >> on a client to connect to the localhost. That is a special > >> case address > meaning > >> "local network". If anything, it would be sending packets out > >> the NIC card, not via loopback. > > 0.0.0.0 means "all IPv4 interfaces available" and only applies > > for binding a server socket. You can never connect to "0.0.0.0" > > as a client. > > > Chris - It actually has a different meaning based on use. For > binding to a socket in the local IP stack, it means what you > say. In the routing table, it means the default route. In > firewalls/routers, it probably means something completely > different. When used as a destination address, it means what I > said. How the IP stack/hardware deals with it is dependent on > the implementation. The RFCs specify that it should be treated > the same as the broadcast address, but local network only, and > not routable. That may be for received packets only, as I've > seen other references that it should never be used on-the-wire, > unless as the source address in protocols like DHCP. In any > event, definitely not expect the 0.0.0.0. address to get any > response, either local host or otherwise. For the OP's specific > problem, s/he need to see how "localhost" is resolving. Most > systems define it in the local "hosts" file, either /etc/hosts > (*nix) or c:\Windows\system32\etc\hosts. Not sure for other > systems. Jeff > >>> Make that C:\Windows\system32\drivers\etc\hosts. > >>> > >>> I did a test and it appeared that ping didn't rely on the entry > >>> being there, but it could have been a cached result. > >> Way back in the day when I had the misfortune to use Windows regularly > >> for stuff like this, I seem to recall that almost nothing short of a > >> reboot would cause the "hosts" file to be re-read. > >> > >> - -chris > > > > > > If I remember correctly, the Windows resolver cache may be cleared from > > a command prompt with ipconfig and that should include entries from the > > hosts file. Seems like I may have had to restart the browser though to > > see any changes to the hosts file. > > ipconfig /flushdns MG> ipconfig/flushdns *should* flush the ips and the dns entries to test use a browser that doesnt cache dns entries (like firefox) go to address bar about:config network.dnsCacheExpirationGracePeriod http://kb.mozillazine.org/Network.dnsCacheExpiration hth, Martin MG> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
... but if the server is a *nix implementation, the better diag tool might be dig. And yes, I would not expect the address 0.0.0.0 on a client to connect to the localhost. That is a special case address meaning "local network". If anything, it would be sending packets out the NIC card, not via loopback. 0.0.0.0 means "all IPv4 interfaces available" and only applies for binding a server socket. You can never connect to "0.0.0.0" as a client. Chris - It actually has a different meaning based on use. For binding to a socket in the local IP stack, it means what you say. In the routing table, it means the default route. In firewalls/routers, it probably means something completely different. When used as a destination address, it means what I said. How the IP stack/hardware deals with it is dependent on the implementation. The RFCs specify that it should be treated the same as the broadcast address, but local network only, and not routable. That may be for received packets only, as I've seen other references that it should never be used on-the-wire, unless as the source address in protocols like DHCP. In any event, definitely not expect the 0.0.0.0. address to get any response, either local host or otherwise. For the OP's specific problem, s/he need to see how "localhost" is resolving. Most systems define it in the local "hosts" file, either /etc/hosts (*nix) or c:\Windows\system32\etc\hosts. Not sure for other systems. Jeff Make that C:\Windows\system32\drivers\etc\hosts. I did a test and it appeared that ping didn't rely on the entry being there, but it could have been a cached result. Way back in the day when I had the misfortune to use Windows regularly for stuff like this, I seem to recall that almost nothing short of a reboot would cause the "hosts" file to be re-read. - -chris If I remember correctly, the Windows resolver cache may be cleared from a command prompt with ipconfig and that should include entries from the hosts file. Seems like I may have had to restart the browser though to see any changes to the hosts file. ipconfig /flushdns - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
