Community
Participate
Working Groups
Hi, when upgrading from 3.2-M3 to 3.2M5 I discovered the following problem with content assist in java editors: When typing sun.awt. and hitting ctrl-space the content assist window opens and shows its contents. But the UI thread is blocked for the next 10-30 seconds. When navigating through the list the UI gets blocked again on each item, that has no source code attachment. This problem only occur when working behind a firewall. When I disconnect from the network the problem disappears. I assume that some network lookup is done when no source code is available in order to display the api doc tooltip. The problem probably was introduced with 3.2M4 since a colleague of mine told me that he has the same problem with 3.2M4 (he is working for a different company but they have a firewall as well).
What firewall are you using? Blocking the UI thread is covered in bug 129168. Moving to JDT Core to check if they can improve getting remote Javadoc in case of firewalls.
We use the java.net classes to retrieve the javadoc. I don't see what we could do. A workaround would be to use a local javadoc.
You could retrieve the Javadoc in a separate thread to make sure that the timeout set in JDT Core preference is respected.
The timeout is only used when retrieving the method parameters' names. Adding another timeout might be confusing.
I think behind a firewall the best solution is to use a local url.
Sure, I was doing that. I am using local javadoc wherever possible, otherwise 3.2M5 would be unusable for me. I am using content assist every third key-stroke and I am usually doing that to safe time and not to waste it. ;) In my opinion the only option is to separate the lookups from the UI thread. Any operation that has no guarantee how long it will run or how long it will block the current thread should not be put in the UI thread anyway. And retrieving data from a remote network using the java.net package are of such nature. Please keep in mind that this really needs to be fixed. I am the only one in my company that figured out what the problem is and what workaround could be used. Other reports from colleagues where much less specific like: "M4/M5 gets stuck every couple of times." Even disabling the javadoc lookup feature from a preference page is of no great help if the user does not know that the UI freeze has something to do with network lookups and is caused by this feature.
Created attachment 37181 [details] Error log Yes, I am behind a firewall too. I have to configure a http proxy to connect on internet. The problem still occurs with Eclipse 3.2 I20060328-0010. Another test : I remove javadoc attachement in JRE configuration. So neither src.zip nor http://java.sun.com/j2se/1.5.0/docs/api/ are configured in my jre. For each runtime jars. Source attachement : (none) Javadoc location : (none) And the problem still occurs ! How to disable remote javadoc check-out when we are behind a firewall ? My error log with new full stack trace is in attachement.
Indeed strange that it happens without any attachements.
*** Bug 133817 has been marked as a duplicate of this bug. ***
>I think behind a firewall the best solution is to use a local url. The API should detect this case and be smart otherwise every client of that API will be affected when used behind a firewall and the user might not immediately know why something is taking so long. If this case can't be detected I see two solutions: 1) allow clients to specify a timeout via API 2) add a preference for this 3) apply your own internal timeout but this might be problematic
*** Bug 134061 has been marked as a duplicate of this bug. ***
The problem seems to be that the javadoc property is still set for the package fragment root even if the javadoc attachment has been removed.
I see three issues there. 1) If the source attachment is removed, looking for it should return null. 2) If a connection failed, I wonder if we do the right thing to log the error. If a user has no connection (because the internet is temporary down), he will end up with the .log file swamped with connection failures. 3) Once a connection failed for a type, we should remember it and not try to retrieve the doc again next time. I'll investigate why the javadoc attachment is still found even if it was removed. I don't plan to fix this for M6 as this might be a pretty risky fix, but I'll try to fix it asap post M6.
I could not reproduce the caching problem with current build. Damien, Could you please try to reproduce your issue in comment 7 with the upcoming 20060330-1200 build ? Thanks.
I will try asap, but I'm pretty busy this week. Next monday will be better for me to make new tests.
I tried with Eclipse 3.2m6, the ui thread is still blocked when Eclipse tries to checkout remote javadoc. Same result if javadoc attachement is "none" in jre configuration.
What did you do to remove the javadoc attachment? It looks like somehow the javadoc attachment is not completely removed.
I edited the javadoc location, then removed manually the link and finally clicked ok, for each jvm jars.
Can you try to put the link back and then remove it using Apply + OK? If it works, there is a bug in the way the preference is removed if using only OK. Thanks. I can also add some tracing in debug mode to display the javadoc location. Then it would be trivial to find out whether the value is removed or not.
I think we have two problems here: - code assist is too slow and blocks the UI thread. - even if the javadoc attachment is gone, retrieving the javadoc still tries to open a connection. I open bug 135604 for the second problem. Markus or Daniel, The only way to fix this would be to add a time out and retrieve the javadoc in a different thread. In what situation is the javadoc retrieved in the UI right now.
> In what situation is the javadoc retrieved in the UI right > now. See bug 129168.
*** Bug 135225 has been marked as a duplicate of this bug. ***
*** Bug 140642 has been marked as a duplicate of this bug. ***
I tested the current solution with 3.2RC3 and things are much better now. The UI doesn't block anymore. I only see a progress bar "Computing additional info" in the status bar (which remains busy for quite some time). But content assist opens straight away. Thank you.
You should thank JDT Text, see bug 129168 ;-)
*** This bug has been marked as a duplicate of bug 129168 ***
