Community
Participate
Working Groups
I received the following error when trying to use content assist after restarting eclipse. Content assist did work before restarting eclipse. error => The extension took too long to return from the 'computeCompletionProposals()' operation. Content assist and organize imports would not work at this point. It wasn't until I pulled up the "Open Type" dialog (ctrl-shift-T) that eclipse started "indexing files" according to UI feedback. After that completed, content assist started working again. Messages from log: eclipse.buildId=I20090611-1540 java.version=1.6.0_14 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -os linux -ws gtk -arch x86 -product org.eclipse.epp.package.java.product !ENTRY org.eclipse.core.resources 2 10035 2009-06-29 11:07:01.572 !MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes. !ENTRY org.eclipse.jdt.ui 2 0 2009-06-29 11:44:00.704 !MESSAGE The 'org.eclipse.jdt.ui.JavaAllCompletionProposalComputer' proposal computer from the 'org.eclipse.jdt.ui' plug-in did not complete normally. The extension took too long to return from the 'computeCompletionProposals()' operation.
Sorry there's not much we can do: it's just a message that it took too long. Also, I am not able to reproduce. Please reopen if you can reproduce and attach the steps here.
.
Try clearing the "type" index - I don't know what exactly it's called or how to clear it except by killing eclipse. It appears the index doesn't get rebuilt when code completion is triggered, which causes the issue with the code completion not working. Once you open the type dialog, the index is rebuilt (you see the status/progress message in the UI) and the code completion works again once this indexing completes.
I see it now. The problem is that code assist starts to use the Java model if the index is not yet up to date. You can either wait until the indexer is done or increase the timeout by setting the'org.eclipse.jdt.ui.codeAssistTimeout' Java environment variable when starting Eclipse, e.g. -vmargs -Dorg.eclipse.jdt.ui.codeAssistTimeout=60000
It seems to take much longer on the JDT Core side: using a workspace with 'org.eclipse.ui.ide' in source gives me quick result after restart with deleted index using 3.4 but in 3.5 it takes very long (you can verify by setting the timeout to 60000 as indicated in previous comment). Might be related to changes made to fix bug 250685.
Tried the same using my dev workspace with many source plug-ins: in 3.4 content assist gives me result quite quickly (<5s) even though the indexer is still running.
The patch attached to bug 281598 also fixes this issue...
Released for 3.6M1 in HEAD stream (see bug 281598 comment 16).
Released for 3.5.1 in R3_5_maintenance stream.
Verified for 3.6M1 using build I20090803-1300
Verified for 3.5.1 RC2 using M20090826-1100
I am still facing this issue in latest HELIOS version. My project also has large number of dependency libraries and jars. I am okay for the computation to take long time, but the problem is that UI hangs for this much time. In my opinion the real fix for this problem is to take out this computation from the UI thread and do it in a different worker thread. Also user should be provided with a progress indicator and an option to cancel this computation. In my understanding the optimizations alone wont scale.
(In reply to comment #12) The content assist should timeout in 5 seconds (default time). Generally with completion, you expect the answer at that point of time and you will not want to do anything other at this point of time and hence I don't see a reason why this should happen in another thread. However, we could be going wrong in some cases and would like to fix them. Are you running into this problem only at the start or through out? Can you give some thread dumps while content assist is taking some time? You could open a new bug for this.
> You could open a new bug for this. See bug 332631.
