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.
This bug was originally marked as duplicate of bug 183606, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.2 (Build 201207171143) VM: Java HotSpot(TM) 64-Bit Server VM, 23.1-b03, Java(TM) SE Runtime Environment, 1.7.0_05-b05 OS: Windows 7 User Comments: GUEST: Syncronize files php, after saving files Maximum slowness yet reported was 65015 ms, average is 65015
Created attachment 126027 [details] nps snapshot
jardo, you changed the summary to: 65s - subversion.client.SvnClientInvocationHandler.handle() blocks simple fs operation in EDT. Why? The only report that contains a call to svn is #618978. Maybe i am reading the snapshot incorrectly, but the way i see it is that a subversion command is running asynchronously. True, it's taking long but i doubt we can speed it up. The problem seems to be someone (indexing?) is trying to create a folder in AWT: org.netbeans.modules.parsing.impl.indexing.CacheFolder.getDataFolder() 100.0 55 001 ms (100%) 0,000 ms 1 Well, shouldn't it be fixed there?? Thanks for explanation.
Looking at the snapshot: The problem is that the EDT is in fact not blocked by IO, but it sleeps in wait in FileObjectFactory.getFileObject(). All the file system operations are blocked ~55s waiting until SVnInvocationHandler completes - in fact it's not a background operation as it runs under global lock blocking all the other threads. It should probably use snapshots.
In this particular case I can help by caching the URL->FO mapping and not asking for a FO but the VCSInvocationHandler seems to block all FS operations.
A SVN operation under a global lock is what I have seen. It needs to be executed without holding the lock, thus assigned to SVN.
> GUEST: Syncronize files php, after saving files Subversion commands run underneath NB FileSystems, in this case because someone called FO.delete on a svn versioned file. We cannot influence whether the lock is taken or not (filesystems should probably decide). But this is the same problem as if FO.delete was called on a non-versioned file and it gets stuck in java.io.File.delete (i assume on windows filesystems it can happen easily). True, svn takes probably longer, i can try a simple hack to bypass the code that resulted in the slowness, however there's still a possibility subversion might stuck somewhere while deleting files. Anyway, i noticed from the snapshot this happened while PHP.CopySupport was doing some synchronization. From what i get it seems that user was trying to copy something via the PHP CS feature to a subversion managed disk area. I do not understand why someone would actually do it, i suggest either completely remove subversion metadata and leave the target area unmanaged or use our disconnect feature for the target topmost subversion-managed folder (Team -> Subversion ->Disconnect). Or equivalently start the IDE with -J-Dversioning.unversionedFolders=PATH_TO_TARGET_FOLDER
fix: http://hg.netbeans.org/core-main/rev/b678aae3fb60
> fix: http://hg.netbeans.org/core-main/rev/b678aae3fb60 made a slight improvement
Fwiw, I do not use subversion (unless Netbeans is running something under my nose). I use mercurial. Scanning Projects was taking a lot of time scanning while I was committing. In a separate test, I tried to just commit my work via command prompt while Netbeans was open and scanning. hg.exe sat around saying I (Netbeans) was holding a lock on some files it needed, so it just waited around until it timed out a few minutes later. Perhaps that was what was happening here as well? I've not taken a good look at what my snapshot generated or how NB's code looks, but I just wanted to note that for me it 'seemed' like an issue with how mercurial and netbeans interacted than subversion.
Integrated into 'main-golden', will be available in build *201211030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b678aae3fb60 User: Ondrej Vrabec <ovrabec@netbeans.org> Log: #220194 - 65s - subversion.client.SvnClientInvocationHandler.handle() blocks simple fs operation in EDT try to bypass evidently a slight slow method isVersioned for most cases