Community
Participate
Working Groups
I have a Resource project of ca. 60,000 files. When saving a file, Eclipse suddenly became unresponsive. See picture.
Created attachment 19723 [details] Shows Eclipse in the "Not responding" state
Created attachment 19724 [details] The only thread not in the waiting state is the thread shown in the picture
Suspending execution of Eclipse and resuming multiple times, always shows it busy "reporting encoding changes"... Thread [Worker-14] (Suspended) FileSpec.equals(String, int) line: 49 ContentType.hasFileSpec(String, int) line: 421 ContentType.internalIsAssociatedWith(ContentTypeCatalog, String) line: 510 ContentType.isAssociatedWith(String) line: 556 CharsetDeltaJob$2.isAffected(ResourceInfo, IPathRequestor) line: 107 CharsetDeltaJob$3.visitElement(ElementTree, IPathRequestor, Object) line: 121 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 81 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) line: 85 ElementTreeIterator.iterate(IElementContentVisitor) line: 119 CharsetDeltaJob.processNextEvent (CharsetDeltaJob$ICharsetListenerFilter, IProgressMonitor) line: 131 CharsetDeltaJob.run(IProgressMonitor) line: 159 Worker.run() line: 67
After about 10 minutes of 100% CPU utilisation, Eclipse resumes normal operation and there is no sign of anything have gone wrong. Scalability issue? Normally I develop under Eclipse Linux GTK, but when this happened I brought the project up on a Windows PC running Eclipse. I haven't observed this problem under Linux. Øyvind
Rafael?
Øyvind, have you made any kind of changes to a content type (adding/removing file name associations, changing the default charset)? That would explain why the job was triggered. That job does a full element tree traversal for a non-critical task (notifying clients of potential encoding changes to files). The bigger the number of files, the longer it will take to finish. And once it started, no workspace operations will proceed until it is done. Need to investigate whether the checking done by the filter: if (info.getType() != IResource.FILE) return false; return event.getContentType().isAssociatedWith(requestor.requestName()); could be made faster. Snapshots also do full traversals and surely don't take that long. If that is not possible (due to the amount of work that has to be performed), should consider breaking the work into smaller units. Not sure how/if that can be done, though. Adding John, the element tree/performance guy, for any insights.
>Øyvind, have you made any kind of changes to a content type (adding/removing >file name associations, changing the default charset)? That would explain why >the job was triggered. Yes. I checked out the project under Windows. Normally I work under Linux. Øyvind
Øyvind, your anser does not seem related to the question I asked. My intention was to ask: did you do any changes to content types, by using the new content type preference dialog (General > Editors > Content types)?
>Øyvind, your anser does not seem related to the question I asked. My intention >was to ask: did you do any changes to content types, by using the new content >type preference dialog (General > Editors > Content types)? No. But I suppose the defaults between my Linux & Windows box might be different.
I'm also seeing this problem on Red Hat Enterprise Linux 3. It appears to be causing problems along the same lines as Bug 74392. If as Rafael said in Comment #6 this job traverses all file resources and blocks all workspace operations until it's done that's a HUGE scalability problem... I can't see my users taking well to their workspace locking up for the 10-15 minutes a file traversal takes over some of my projects...
Created attachment 21608 [details] Stack trace of encoding changes lock up This is a a stacktrace from a lock up related to the encoding changes. This problem was created by: 1) Creating a new project over a large code base with high latency io (see Bug 74392 ). 2) Open a file. (The Encoding Changes job appears at this point). 3) Place the cursor in the file and hit enter. (lock up occurs). Please note, this seems to lock the entire UI. So far I haven't seen the UI come back from this problem.
Will investigate a fix for this asap.
I could not reproduce the problem with n200505270900, even if running in debug mode. It never takes more than a few seconds. My scenario: a project containing 256 directories, each one containing 256 files, total number of files is 65536 on a Netware drive. Øyvind, was your project on a local or remote file system? Were you using the Eclipse SDK only? Which build? Ed, can you reproduce the problem if you open the project with a recent Eclipse SDK only (no other plug-ins installed)?
>Øyvind, was your project on a local or remote file system? On a local Windows machine, I imported a project that I had previously developed under Linux. >Were you using the Eclipse SDK only? Which build? It's been a while, I think M5 or M6. Haven't tested on M7. If I get a chance, I'll try to reproduce it on M7 tonight. Øyvind
Created attachment 21908 [details] Shows not responding while deleting lotsof resources The project I'm deleting has ca. 60000 files. This was with M7, but can't investigate any more right now. The cycle for testing is fairly long with 60000 files :-) I never got as far as deleting the old project and rechecking it out from CVS, which was my original plan. - Under Windows w/Eclipse M7 - create project w/60000 files - delete it - while deleting is running, minimize, maximize Eclipse window and move it about. Eventually it will show "Not responding"....
Trying to reproduce again with JUST Eclipse SDK 3.1M7 ( Build id: I20050513-1415 ) without any additional plugins (I'm sure of this, I literally just untarred a new instance) I cannot reproduce the problem. I then attempted to reproduce the problem with vanilla Eclipe SDK 3.1M7 plus a recent CDT build. Still couldn't reproduce the problem. When I try it with Eclipse SDK 3.1M8 plus the CVS org.eclipse.core.resources from CVS that I had slightly modified to change the background refresh throttling the problem is reliably reproducable. As my changes are minor and unrelated (I think) this makes me (slightly) suspicious of the CVS core.resources. That said, I will be doing due dilligence to check out a clean CVCS core.resources and try to reproduce (please keep in mind, reproducing is a bit time consuming for me :) ). I thought it good to get the data I had to date out asap though.
I used the following code to create 64K *.txt files under a project (created externally - a refresh on the project brings them to the workspace): import java.io.File; import java.io.IOException; public class Main { public static void main(String[] args) throws IOException { File root = new File(args[0]); root.mkdirs(); for (int i = 0; i < 256; i++) { File dir = new File(root, Integer.toHexString(i)); dir.mkdir(); for (int j = 0; j < 256; j++) { File file = new File(dir, Integer.toHexString(j) + ".txt"); file.createNewFile(); } } } } Then to trigger the "Reporting encoding changes" background job, I would go to the preferences page for content types, select the Text content type, set the default charset to something different, and press the associated Update button ("Ok" is no enough). If you have the progress view settings to show "sleeping and system tasks", it should show the job running for a couple of seconds.
Please reopen if any of you can provide a reproducible test case for this on 3.1. Thanks.
Marking as "remind".
I have a workspace with a few thousand files. I copied all of the files from one disk to another, and when I start eclipse up for the first time, it gets stuck in the "Reporting Encoding Changes". This is on Linux (FC6) -- I did this when migrating from FC4 -> FC6, but that probably didn't have anything to do with anything. I also did chown/chgrp on all of the files that were copied. This all happens on Eclipse 3.2.1.
[REMIND->INVALID] Reopening to mark this bug as invalid because sufficient details were not provided.
[REMIND->INVALID] Marking this bug as invalid because sufficient details were not provided.
Can this issue be reopened? I have a workspace I can attach where this problem occurs on Windows XP. Tested on Windows 7 and the problem does not occur. Eclipse SDK Version 3.6.1.
I tried to attach the zipped workspace and not able to attach. Is there another way I can send the zipped workspace (> 10M)?
Nevermind about reopening. Found an alternate solution.
Quick solution will be Close all projects and then add content types / file associations. Then Open project
