New project wizard is locked when it tries to create a project in mercurial repository and other mercurial thread is
running. It breaks commit validation tests often since build 20080130-2221. To reproduce:
- run IDE with usedir in Hg repository (e.g. main/myuserdir - this case is common when you run UI tests)
- there should be "Changing..." task running in progress bar (I don't know what it is doing)
- immediatelly open new project wizard
- choose Ruby|Ruby Application and click Next
- select project location inside your userdir
- click Finish. The New Project wizard is never closed and the "Changing" task is never finished (see attached thread dump)
You can also reproduce it in tests:
Product Version: NetBeans IDE Dev (Build 20080131071558)
Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Created attachment 55835 [details]
Created attachment 55836 [details]
Mercurial task has not finished for some reason. Not sure why. Reassigning.
I can reproduce this when I attempt to create Ruby project in main.
Looking at the thread dump I see a thread BLOCKED after call to Sharability.getSharability after call to
FileStatusCache.refresh in fileChangedImpl in MercurialInterceptor.java.
Another thread is WAITING for the RequestProcessor being used by the4 previously mentioned thread in HgMoveImplementation.
My proposed fix will not call FileStatusCache.refresh in fileChangedImpl for files which Mercurial is ignoring.
This is a _GOOD_ thing to do in any case as it does not make sens to update the cache at this point for files which are
It has the added benefit of fixing this bug.
I also wonder why mercurial plugin is doing something ("Changed..." task) when IDE is opened. There are no project
opened, only userdir is under mercurial repository.
My intended fix does not seem to address the root cause. I need to look further.
We seem to have our RequestProcessor thread hanging for some reason which prevents us using it
do to a move.
Does cancelling the "Changing" task help?
As to why we see "Changing ..." if one adds -J-Dorg.netbeans.modules.mercurial.level=100
to netbeans_default_options the output in messages.log may give us a clue as to what files
are being reported as changed.
> Does cancelling the "Changing" task help?
Actually there is at least 5 tasks queued and if you cancel one, another new appear. I will attach requested log.
Created attachment 55892 [details]
messages.log with mercurial logging.
I think that the cause of the problem is the waitFinished call in hgMoveImplementation. This seems to cause the lock
contention I see in the thread dump.
The thread in which hgMoveImplementation is called has locked a NamingFactory. Another thread which is waiting to
lock NamingFactory has locked a SynchronizedMap. The thread in which FileStatuscache.refresh is called is waiting to
lock the SynchronizedMap.
Removing the waitFinished call should allow the threads to proceed. The effect of this is the the move will not have
actually have been done when hgMoveImplementation has finished. The reason we must do the move in our RequestProcessor
is that we need to determine the status of the file being moved to determine how to move it.
*** Issue 126323 has been marked as a duplicate of this issue. ***
Created attachment 55903 [details]
Created attachment 55906 [details]
date: Fri Feb 01 11:50:03 2008 +0000
126385: Do not call waitFinished() in hgMoveImplementation. This fixes lock cont
126414: Check for ignored file when moving
Do not refresh cache for ignored file in FileChangedImpl
date: Fri Feb 01 11:47:10 2008 +0000
*** Issue 126663 has been marked as a duplicate of this issue. ***