Relates :
|
|
Relates :
|
|
Relates :
|
When creating URLs in an applet I experience 5 second delays. This is because the JVM is attempting to do a DNS lookup of my webproxy but my webproxy doesn't have a DNS entry. This is a fairly typical setup for corporate web proxies. The problem is in sun.net.www.HttpClient.priviledgedOpenServer() which makes a call to InetSocketAddress.getHostName(). This is a new issue that has appered in 1.5.0. I can't see any reason why the JVM would need to resolve the name of the proxy. So I think this is a bug. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1. Configure your web browser to use an HTTP proxy which you specify by ip and port (not by hostname). 2. Host the applet below on a webside accessed through the web proxy. 3. Arrange some method of detecting network lookups. 4. Load the applet in the browser EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - I'd expect the URL connections to be instantanious. I'd expect no name lookups to take place. ACTUAL - Name lookups of the web proxy take place. On an incorrectly configured system this causes the URL connection to take 4 seconds or longer. REPRODUCIBILITY : This bug can be reproduced always. ---------- BEGIN SOURCE ---------- import java.applet.Applet; import java.io.IOException; import java.net.URL; import java.net.URLConnection; public class Minimal extends Applet { public void start() { try { for (int i = 0; i < 5; i++) { long time_start = System.currentTimeMillis(); URLConnection uc; URL url = new URL("http://foo.com"); uc = url.openConnection(); uc.connect(); long time_end = System.currentTimeMillis(); System.out.println("Time to open socket (ms): " + (time_end - time_start)); } } catch (IOException e) { System.out.println(e); } } } This issue is separate to 5092063 even though it looks similar. I have recently tested the 1.5.0_08 JVM and the issue is still there. The good news is, thanks to SUN's open source code policy, I can tell you exactly where the bug is: It is in sun/net/www/HttpClient.java in the privilegedOpenServer() method. In here there is a call to server.getHostName() which forces the InetSocketAddr object to resolve its name (if it hasn't done so already). Backtracking a little... The problem is when someone is using a java applet to connect through a web proxy. On some networks the proxy has been specified by ip address but does not resolve into a host name (I reproduce this by using a Perl proxy for an ipaddress which doesn't have a DNS record on our LAN). I suspect the issue exists on many platforms but it is particularly accute on windows since when a DNS lookup fails windows attempts to lookup via NetBIOS (or something simlar) which results in a failed lookup taking 4.5 seconds! The problem is that with the new Proxy code in 1.5, the priviledgedOpenServer() method is called whenever an applet makes a connection. It isn't possible to bypass this call or bypass / alter the Proxy code without generating security exceptions. There are two obvious fixes that could be applied: 1. Fix priviledgedOpenSever() so that it doesn't call getHostName(). I see no reason why it should resolve the name, it seems like a bug to me. If the proxy is specified by ip address then ip addresses only should be used for connecting to the proxy. 2. Fix the ProxySelector stuff so that it returns the same InetSocketAddress object each time it is queried. I couldn't find the source for this since some of it is native, but it appears that each time you query the ProxySelector for the proxy details it returns a new InetSocketAddress object. InetSocketAddress objects cache their name if you attempt to look it up, so if the ProxySelector returned the same object each time then the lookup failure would only need to be performed once (I still can't see any reason why it should be performed at all, but this would at least be an acceptable workaround).
|