This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Hi. I have CVS filesystems on a NFS disk (using from linux) and right now the disk access is slow (probably). The ide likes to block for ages. I have threaddump which shows that JavaCVS FS is involved. I am not saying that the bug is in your code just that your code exhibits a pretty serios performance bug. Please evaluate this somehow and explain why everything is so slow... I am using KDE and I switch from IDE virtual desktop to another desktop and back. Than everything blocks.
Created attachment 2702 [details] AWT and RequestProcessor threads blocked.
Created attachment 2703 [details] Another thread snapshot
Created attachment 2704 [details] My mounted filesystems. Expects that /home/jarda/work is netbeans repository
Created attachment 2706 [details] I have disabled calls to annotateName&Icon and still the request processor is occupied by JavaCvs. Why?
Seems like the CacheDir reads and writes a content of cache periodically. "OpenIDE Request Processor-0" daemon prio=1 tid=0x8238fa0 nid=0x7b1b runnable [0x4e8fe000..0x4e8fe890] at java.io.FileOutputStream.close(Native Method) at java.io.FilterOutputStream.close(FilterOutputStream.java:146) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:259) at java.io.BufferedWriter.close(BufferedWriter.java:247) at org.netbeans.modules.javacvs.caching.CvsCacheDir.simpleWriteToDisk(CvsCacheDir.java:238) at org.netbeans.modules.javacvs.caching.CvsCacheDir.writeToDisk(CvsCacheDir.java:260) at org.netbeans.modules.javacvs.caching.CvsCacheDir.setModified(CvsCacheDir.java:552) at org.netbeans.modules.javacvs.caching.CvsCacheFile.setStatus(CvsCacheFile.java:234)
*grin* I have been just working on that today. I've changed the caching lately and the place that seems to stuck the IDE is a residuum of older stuff. I've removed it. Explanation: Previously the disk cache was read only when the annotation was required. However this was causing constanly problems with 'virtual' files, that were not returned by Filesystem.children() calls but were discovered later during annotateName(). To get these files to the display, the directory had to be refreshed. Which in turn called children + annotatename again. Lately (probably because of slight changes in the threading model, or raised requirements on the fs from various threads) I had to synchronize some methods, so that the cache doesn't break and throw exceptions. It slowed down the caching and seemed to create deadlocks. I've tried to solved it by postponing the refresh, (that the code that seems to be appearing in the thread dumps) So now the disk cache *is* consulted during the children() call and no subsequent refresh is nessesary. This is actually done *only* the first time the directory is accessed and later is only read after refresh or any other cvs command that updates the cache on large scale. I think this way it is at least equal to the previous solution which was doing it at least twice (I suspect under certaion conditions I couldn't 100% reproduce) it was doing so recursively and hang the IDE. to further speed up the reading of the cache, I'm currently storing only the cvs related files. (Previously there were stored all the files and directories.) Please check tomorrow's build and let me know if the problem still persists.
additional comments: When the cache is not built yet, eg. when there's no netbeans.cache file in the CVS subdir, then a refresh command is executed for this directory. This behaviour is regulated by the filesystem's autorefresh property. The current default value is as described above. Changing it to something else , like do recursive refresh upon mounting the filesystem might help to get a bit quicker response. however this might not be true.
I believe the performance is better now and therefore verify it. On the other hand I am sure that Jarda will reopen this issue if he is not satisfied with the fix. Am I right ? :-) Development build #200110100100 of NetBeans 3.3
Resolved for 3.4.x or earlier, no new info since then -> closing.