Created attachment 57672 [details]
stacktrace

reassigning for eveluation

DiffResultsView.showDiff -> cancelBackgroundTasks in RQ which is constructed to interrupt threads when
RequestProcessor.Task.cancel is called

Can you clarify what the test case to reproduce this it?
I cannot reproduce from the information provided.

I tried to reproduce without any success now. 

1) Invoke Mercurial | Show History
2) Push Search
3) Push the Diff toggle button
4) Select some file

It can be random, maybe rmatous can advice how to fix it?

In project window right click project/subversion/show changes, reload, click x in progress bar at bottom right corner of
nb -> exception

Created attachment 58300 [details]
ide log

While the attached ide log shows a similar exception it it nothing to do with mercurial as it is occurring with
Subversion plugin.

Build: NetBeans IDE Dev (Build 080318)
VM: Java HotSpot(TM) Client VM, 1.5.0_13-b05
OS: Linux, 2.6.22-14-generic, i386

User Comments: 

Created attachment 58684 [details]
stacktrace

There is nothing in the latest stack trace to indicate that it has anything to do with the mercurial plugin.

Perhaps bug isnt in mercurial plugin but somewhere else. Perhaps bug needs to be reassigned.

Can you suggest a logical place to reassign it?

Any suggestion for reassigning Tomas?

This issue has already 10 duplicates 

Created attachment 61421 [details]
stacktrace

Not sure where this should go, not mercurial specific. Will reassign to version control so maros can evaluate.

Created attachment 62136 [details]
stacktrace

Build: NetBeans IDE Dev (Build 200807221016)
VM: Java HotSpot(TM) Client VM, 11.0-b12, Java(TM) SE Runtime Environment, 1.6.0_10-beta-b25
OS: Windows Vista, 6.0, x86

User Comments: 
Closed diff window while it was retriving files from repository

Stacktrace: 
java.lang.InterruptedException
        at java.lang.Object.wait(Object.java:0)
        at java.lang.Object.wait(Object.java:485)
        at org.openide.util.Mutex$QueueCell.sleep(Mutex.java:1601)
        at org.openide.util.Mutex.enterImpl(Mutex.java:723)
        at org.openide.util.Mutex.enter(Mutex.java:630)
        at org.openide.util.Mutex.readEnter(Mutex.java:613)

Created attachment 65439 [details]
stacktrace

41 duplicates so far ...
abs: 	When I try to create folder named "lib", exception was thrown.
ebleicher: 	In the Projects window, right-click the SynchronousSampleApplication project node and choose Add JBI Module
from the pop-up menu. The Select Project dialog box opens.
GUEST: 	Import into svn
novakm: 	I invoked Mercurial | Show History and selected Diff togglebutton and selected one file.
GUEST: 	Importing files into a PHP project from an existing source directory
GUEST: 	did big diff and cancelled
sunbiz: 	Closed diff window while it was retriving files from repository
lstroud: 	trying to refresh mercurial status
GUEST: 	adding a jarfile to the libraries
buzzword: 	Stopped a second concurrent testcase execution.

Build: NetBeans IDE Dev (Build 200808280201)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Windows XP, 5.1, x86

User Comments: 
Adding a jar file by typing the the name ( I may of had the case wrong or something)

Stacktrace: 
java.lang.InterruptedException
        at java.lang.Object.wait(Object.java:0)
        at java.lang.Object.wait(Object.java:485)
        at org.openide.util.Mutex$QueueCell.sleep(Mutex.java:1601)
        at org.openide.util.Mutex.enterImpl(Mutex.java:723)
        at org.openide.util.Mutex.enter(Mutex.java:630)
        at org.openide.util.Mutex.readEnter(Mutex.java:613)

Created attachment 68674 [details]
stacktrace

Exceptions reporter mixes unrelated problems together, which stack trace are we supposed to reproduce and resolve here?

I think this is a general problem when a thread waiting in some masterfs operation is interrupted. Stack traces vary
from mercurial, svn and versioning to php, j2ee and j2se project. Masterfs guys please evaluate, should
InterruptedException be handled separately in all modules? In my opinion the exception should be caught and handled on
your side since code calling FileUtil.toFile() is not expecting an InterruptedException.

It seems InterruptedException from Mutex.QueueCell.sleep is harmless and it is a valid use case that thread waiting in
Mutex.QueueCell.sleep can be interrupted. That's why I suggest to change message level from WARNING to INFO. BTW, it was
changed reversely in the past without any particular explanation.
Discussing this issue with Andrei Badei he pointed out that interrupted flag should be set afterwards, if
InterruptedException is caught. Please, review my patch and share your opinion. Thanks.

Created attachment 69379 [details]
Patch of Mutex.QueueCell.sleep.

Nice. Possibly consider an apichanges.xml note about the interrupt behaviour (that would imply increment of spec 
version).

Really Mutex.readAccess should be throwing the IE to clients, as JDK concurrency utilities would do. Since this is a
checked exception, we cannot make that change now. I would suggest throwing an IllegalStateException or similar from the
Mutex call (with the IE as root cause); a client should reasonably expect that if a Mutex call documented to be blocking
returns normally, the block has actually run.

After lunch discussion about the problem I think throwing an IllegalStateException is too aggressive. If client wants to
know about thread state, it can check Thread.isInterrupted() and proceed adequately. I would apply original patch.

I am not sure I understand correctly when the ISE was supposed to thrown, but if the proposal is to replace 
LOG.log(ex) with throw new ISE(ex), then I have to worn it is incompatible change. Personally I would not like such 
change at all.

Yes, the proposal is to replace LOG.log(ex) with throw new ISE(ex). Perhaps this could be considered incompatible
(though with no apparently documented specification) but I would consider it a bug fix. If you ran

someMutex.readAccess(new Mutex.Action<Void>() {
  public Void run() {
    doSomething();
    return null;
  }
});

and this returned without throwing an exception yet doSomething() was not in fact run, that would clearly be treated as
a defect in the Mutex implementation. No one is going to think to check Thread.interrupted() (or want to).

If on the other hand the interruption of cell.sleep() is just ignored (i.e. thread goes back to sleep until it gets the
mutex) this also seems like a defective implementation; you would expect that interrupting the thread would actually
stop it from waiting for the lock. Why else would you interrupt it?

I would support the addition of new methods such as

public <T> T readAccessInterruptibly(final Action<T> action) throws InterruptedException;

(compare java.util.concurrent.Lock.lockInterruptibly) which would throw the IE directly if the thread were interrupted
while waiting to acquire the lock (or the interrupt status were set upon entry to the method). This would allow Mutex
clients to explicitly handle external interrupts and perhaps terminate their work gracefully. In such a case the
existing methods could set the interrupt flag (do not log any exception above FINE), and the documentation of the
existing methods should be changed to clarify that they block uninterruptibly, again matching the behavior of e.g.
Lock.lock().

Reassigning because I am not able to judge what is the best solution. Anyway I don't agree with the proposal to replace
LOG.log(ex) with throw new ISE(ex). It will be the same from users point of view although more correct from design point
of view. Then who should handle ISE?

The ISE solution doesn't look right to me either. First, my experience is that most developers don't read the
documentation, so even new uses of Mutex will fail to handle ISE. 

Second, my understanding of the stack traces attached to the issue is that Thread.interrupt() was not called in an
attempt to interrupt the waiting for the mutex, but in an attempt to interrupt a background task which just happened to
be waiting in the masterfs mutex at that time. It definitely seems to be the case for 

http://www.netbeans.org/nonav/issues/showattachment.cgi/61421/stacktrace.txt

So I'm not sure that the concern that the mutex action will be executed despite the thread having been interrupted is of
great importance.

I was going to suggest the *AccessInterruptibly methods yesterday; I didn't since I realized that would mean six new
methods. But I'm not even sure they are the right thing to do. My understanding of desc32 is that the introduction of
these methods would allow the existing ones to wait uninterruptibly without rethrowing IE as ISE. But the methods
wouldn't be called by anyone, at least not as part of the fix of this issue. Is it a good idea to introduce six new
methods with no known client, even if they are a logical addition to the API?

Another thing:

catch (WhateverExeception e) {
   Exceptions.printStackTrace(e);
}

has become a pattern so common in NetBeans, at least in the upper layers, that I'm afraid the IE (disguised as ISE) will
often end up in the unexpected exception dialog anyway.

It is OK for the existing methods to swallow InterruptedException if

- the Thread interrupt flag is set, so that other code (e.g. the body of the mutex action) can test this flag and choose
to exit early

- no stack trace is logged (since it is not an error condition)

- it is assured that a blocking call which returns normally has in fact run its block

I.e. acceptable logic would be of the form:

public void runNow(Runnable r) {
  while (true) {
    try {
      someLock.wait();
      r.run();
      return;
    } catch (InterruptedException x) {
      Thread.currentThread().interrupt();
      // and continue
    }
  }
}

Adding *Interruptibly methods is just an option. If there is existing code which is expecting to be interruptible by
someone (i.e. is periodically calling interrupted(), or making blocking calls to I/O and exiting quietly upon IE from
these) yet is explicitly acquiring mutexes, then it would very likely be improved by using an interruptible mutex
method, as this would ensure that it did not block indefinitely trying to acquire the mutex.

Since there has been some confusion on this point - it was never my intention that anyone catch ISE. That is why it is
an unchecked exception! The suggestion about ISE was in case the mutex method should exit but had not run its block - in
such a case you must throw an unchecked exception to indicate that execution has not completed normally. There would be
no real recovery in this case and a stack trace would be appropriate. But I think the intended semantics was to keep
waiting for the lock despite the attempted interrupt.

I think runNow() as it is would end up in an infinite loop if the thread is interrupted (when the interrupted flag is
set, Object.wait() will immediately throw IE). Anyway, if the intention is to make sure the interrupted flag is set
before executing the runnable, jskrivanek's patch does that, and the behavior is asserted by the test.

Agreed about the *Interruptibly methods.

This issue has already 50 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=13343

I also think that my patch fulfils all Jesse's requirements, so I applied it.

http://hg.netbeans.org/core-main/rev/94c46f64d1a2

Integrated into 'main-golden', will be available in build *200809121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/94c46f64d1a2
User: Jiri Skrivanek <jskrivanek@netbeans.org>
Log: #129003 - InterruptedException caught in Mutex.QueueCell.sleep is logged only with FINE level and interrupt flag is set, so that other code (e.g. the body of the mutex action) can test this flag and choose to exit early.