Bugzilla – Full Text Bug Listing
| Summary: | Specifying a Classpath Variable Pointing to a Large Directory Locks Up Eclipse | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Robert Krajewski <rpk_pro> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | amj87.iitr, jarthana, satyam.kandula |
| Version: | 3.8 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
|
Description
Robert Krajewski
This only happens if an entry that incorporates a classpath variable ends up denoting a folder with a lot of files. For some reason, there was an entry in my classpath which consisted of the just the classpath variable. There was another that pointed to the specific that I wanted, in terms of the classpath variable. When I removed the first entry, Eclipse came back much faster. It would still be a good idea to address this issue, because this is an easy way to (apparently) lock up Eclipse. (In reply to comment #1) > This only happens if an entry that incorporates a classpath variable ends up > denoting a folder with a lot of files. I'm trying to think of the alternative way in which this can be handled. If the classpath variables is a network volume, and there are a large no. of files on there, the slowness of the process may be limited by the speed of the network more than Eclipse's ability to read the classpath. Jay, do you know if we process the classpath differently based on whether its a local path or a network path? (In reply to comment #2) > Jay, do you know if we process the classpath differently based on whether its a > local path or a network path? No, we don't. (In reply to comment #1) > This only happens if an entry that incorporates a classpath variable ends up > denoting a folder with a lot of files. For some reason, there was an entry in > my classpath which consisted of the just the classpath variable. There was > another that pointed to the specific that I wanted, in terms of the classpath > variable. When I removed the first entry, Eclipse came back much faster. I didn't quite understand this. What is the first entry point to? And is the 'specific' location you are referring to, isn't it your network storage? I'll explain. Among the entries in the classpath were LARGE_DIR and LARGE_DIR/some/specific/module/foo.jar I don't know why the first entry was there, but when I removed it, the problem went away. (In reply to comment #4) > I'll explain. Among the entries in the classpath were > > LARGE_DIR > > and > > LARGE_DIR/some/specific/module/foo.jar > > I don't know why the first entry was there, but when I removed it, the problem > went away. Thanks for clarifying! The network drive (folder) would have been added as an external folder, which requires the link folder to be created. Being larger in size and not locally present, it's understandable why it's slow. Another factor, which is unlikely in your use case, is the linked resource was being refreshed. Even forcing a refresh doesn't take much time for me. The network access must have been very slow. Anyway, since you said it works for you now, closing it. Robert, when you said this is a way to 'lock up' Eclipse, did you mean the UI is hung and you're unable to do anything? If the UI is otherwise responsive, its ok to leave it as it is, but if that's not the case, then maybe there is a way to set some timeout limit and give a JavaModelException when its crossed (Something like we do for fetching javadoc over the network, etc) Yes, the UI is locked up while showing the progress dialog (because it's refreshing/rebuilding). From the Mac OS X Force Quit Applications dialog (the one you get with Command+Option+Esc), it is noted as (not responding). Eclipse itself is definitely reading the directory (I was seeing network read speeds of 300-500 kb/s from Eclipse, and it was using a reasonable percentage – 7-10% – of the CPU). It was definitely busy and not waiting on the network (particularly). It's just that the large directory has a _lot_ of files. I suppose it would come back eventually, but I let it run for three or four minutes. I could reproduce the problem with the variable pointing to a folder with many jars. We probably may not be able to do anything, but I think we should atleast try to find out the real cause of the problem and then decide what we want to do with this. Hence, reopening. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |