Community
Participate
Working Groups
Build 20020205 using Team 2.0 - at home, I have a workspace with a connection to ottcvs1.ott.oti.com - tried opening it - it failed - realized I hadn't connected through VPN - did so (without exiting eclipse) - tried again - it still failed - tried pinging ottcvs1.ott.oti.com -- it worked - restarted eclipse - it then worked
This is a known problem. We believe it is caused by the VM.
*** Bug 19706 has been marked as a duplicate of this bug. ***
readme for 2.0
I believe this is a bug in the IBM JRE. J9 works.
I'd be interested to see a testcase that reproduces this. What are the characteristics of the 'workspace connection'? I tried unsuccessfully to cause the error using a simple HTTP connection with an IBM 1.3.0 install (stopping and starting the HTTP server) -- though I suspect this is not a similar case.
Created attachment 1628 [details] Bogus testcase
*** Bug 21277 has been marked as a duplicate of this bug. ***
Upon further testing, this problems occurs for Sun JREs 1.3.1 and 1.4. The next step will be to write a simple Java program that is independant of Eclipse to see i the problem is somehow related to Eclipse.
I have run the attached test program at home (Windows ME and Shiva VPN) using the following steps: 1) launch the program (TestSockets.java) 2) try to connect - this fails because the host cannot be found 3) start up my VPN client 4) try to connect - this still fails 5) shutdown and restart the program 6) try to connect - this succeeds I have tried this with IBM JRE 1.3.1, Sun JRE 1.3.1 and JRE 1.4 and J9 and they all have the same behavior (I'm not sure why J9 worked before, perhaps I had an earlier version or did something extra that caused it to work). Given the above, it is most likely related to the VPN software. I will be upgrading my OS and VPN shortly and will retest then.
*** Bug 23430 has been marked as a duplicate of this bug. ***
Bug 23430 reports the problem using the Cisco VPN and Sun's JDK 1.4.1
*** Bug 27135 has been marked as a duplicate of this bug. ***
*** Bug 30047 has been marked as a duplicate of this bug. ***
I am seing this problem again in 2.1.RC3a. Version: 2.1.0 Build id: 200303202147
This is still a problem in Version: 2.1.0 Build id: 20030327213.
*** Bug 38096 has been marked as a duplicate of this bug. ***
*** Bug 44389 has been marked as a duplicate of this bug. ***
*** Bug 50368 has been marked as a duplicate of this bug. ***
The default cache time for DNS entries in the Sun 1.4.2 JVM is "cache forever". See "networkaddress.cache.ttl" (third one down): http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html WORKAROUND: If you find you are having this problem regularly you can disable DNS caching with a JVM flag (http://www.rgagnon.com/javadetails/java-0445.html): -Dnetworkaddress.cache.ttl=0 or -Dsun.net.inetaddr.ttl=0[JDK1.3]
Thansks. We'll ad this to the FAQ.
*** Bug 40591 has been marked as a duplicate of this bug. ***
Post 3.0
This bug can also appear when you have issues with ADSL or similar equipment. (for example, in-ability to establish connecton to service host). Anything which causes the connection to be "flakey" when the inital connect is performed. At this point, you might want to check your connection equipment and reboot that, as opposed to resetting your dns caching.
*** Bug 75999 has been marked as a duplicate of this bug. ***
I have found that the -Dnetworkaddress.cache.ttl=0 workaround option does not appear to work from the command line. I believe this property cannot be set from the commmand line (when I try it, it does nothing -- also please see Sun's JVM docs). The appropriate command-line-settable property for Sun's 1.4.2 JVM is: -Dsun.net.inetaddr.ttl=0 (see the following link for further details --> http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html ) To make sure this is set for the actual JVM that Eclipse is running, I suggest letting Eclipse set it, as follows: eclipse.exe -vmargs -Dsun.net.inetaddr.ttl=0
*** Bug 76470 has been marked as a duplicate of this bug. ***
*** Bug 116401 has been marked as a duplicate of this bug. ***
I got send to this page due the duplicate 'Bug 116401'. I tried the workaround "-vmargs -Dsun.net.inetaddr.ttl=0" which doesnt work for me, which could also be caused by me using the blackdown-jdk instead of the sun one. But as i am using plain IPs instead of dns names to connect to (in my case my CVS Server at home), there shouldnt be any lookups at all ?
Sorry about that. I guess I jumped the gun. anyway, Blackdown is not a supported VM. If you can reproduce the problem with a supported VM, then please reopen the original bug.
This is a JVM problem. We have described the problem in the readme file and the CVS FAQ.
*** Bug 157287 has been marked as a duplicate of this bug. ***
Its not purely a JVM problem. Its a general network problem. It can be caused by any participator in the DNS lookup process. back in the day this was a bona fide JVM bug because the JVM would cache its failures too long. Modern JVMs do not cache failures. But if you have not made the proper connections there is a chance your local DNS can return you the wrong IP address which will be cached forever as a success. You can avoid that with networkaddress.cache.ttl There is a 2nd way to have a problem. When JVM connects to an external device like VPN or SSH tunnel, this can disrupt/mask the normal network disconnect/connect etc. notifications to the JVM. Generally this is probably a bug/malbehavior in that 3rd party software you are using for your connection.
