Community
Participate
Working Groups
Build ID: I20080617-2000 This is follow on to bug 214581, where the library detection timeout was increased from 10s to 30s. We still regularly have problems with this timeout, which with a big workspace is very inconvenient. And frankly, the value of 30s feels quite arbitrary to me. I can think of two possible improvements to this situation. The simpler one would be to make the timeout configurable, perhaps by using a command line parameter. That would allow us to set it to a value that works better for us. The more elaborate one would be to somehow let the user decide whether he wants to cancel the library detection job, via the progress view or a dialog.
Libraries are detected using separate process, which executes "java" command and prints certain properties to standard output, which is later captured and processed. The problem with timeout is that we do not have communication between different processes, so even if we had a job wrapping there, it will be impossible to kill it (because job has to listen for cancel). Please note that timeout while discovering libraries means, that simple java command execution takes more than 30 seconds. It also means that launching any other app (debug, test) will take similar time, so it makes Eclipse unusable (for me at least). I'd like to see here more details, because bug 213681 affected only several (older) workstations, and even there it occured quite randomly. Ilja, could you please tell me what is the size of your workbench, what are your computer parameters, etc etc?
This is a 3.5GB Workspace, <300 Java Projects, ~1 MLOC, on a current Intel Dual Core, Windows XP workstation with 2 GB RAM. Things are not always fast, but at least they work in the end - except compilation, which from time to time ends with compiler errors along the lines of "java.lang.Object not found" (which can be "fixed" by changing to a different "installed JRE", and back).
It is a really big workspace - and I am not suprised that you have problems with timeouts. I do not want be intrusive, but please consider if you need all those projects all the time... Compiling those projects into jars and moving those jars to separate project/folder and then manipulating build paths should *drastically* improve performance.
We already considered that several times. Point is, it really is more of one big project, distributed over several Eclipse projects for better dependency management. And we make heavy use of cross-project-refactorings, which would be significantly harder with the proposed setup, as far as I can tell. Therefore we decided that for the time being we'd rather take the performance-bullet. Which works reasonably well for us most of the time, except for the problem with the library detection timeout.
Daniel, would it be acceptable for you to support command line parameter?
Not sure why you are asking me.
