[PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory

[Alex Kashchenko]

Hi Alan,

On 04/10/2016 07:17 AM, Alan Bateman wrote:
> On 09/04/2016 23:23, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review a fix for the windows-specific WatchService problem:
>>
>>  - issue: https://bugs.openjdk.java.net/browse/JDK-8153925
>>  - patch: http://cr.openjdk.java.net/~akasko/jdk8u/8153925/webrev.00/
>>  - reproducer:
>> http://cr.openjdk.java.net/~akasko/jdk8u/8153925/reproducer.00/GetOverlappedResultHangsTest.java
>>
>>  - original JBoss Tools issue:
>> https://issues.jboss.org/browse/JBIDE-22078
>>
>> The patch adds an additional flag to WindowsWatchKey that is set to
>> true when ReadDirectoryChangesW call fails. If the flag is set then
>> GetOverlappedResult won't be called after CancelIo call during key
>> invalidation.
>>
> Would you mind bringing this to nio-dev for discussion with more details
> as to how the issue arises?

CC'ing nio-dev.

The issue appeared during the deployment of a WAR from Eclipse+JBoss 
Tools to local WildFly instance. It caused deployment errors with a 
message: "Error renaming [tmp/some_file] to [app.war/some_file]"

It was tracked down to the directory locked infinitely by the 
WatchService with the following trace of the poller thread:

     WindowsNativeDispatcher.GetOverlappedResult(long, long) line: not 
available [native method]
 
WindowsWatchService$Poller.releaseResources(WindowsWatchService$WindowsWatchKey) 
line: 460	
     WindowsWatchService$Poller.access$100(WindowsWatchService$Poller, 
WindowsWatchService$WindowsWatchKey) line: 244	
     WindowsWatchService$WindowsWatchKey.invalidate() line: 180	
     WindowsWatchService$Poller.implCancelKey(WatchKey) line: 495	
     WindowsWatchService$Poller.run() line: 634	
     Thread.run() line: 745

 From ProcMon it was noticed that just before this call poller thread 
calls ReadDirectoryChangesW that fails with "DELETE_PENDING" status. It 
looked like in this case overlapped I/O operation failed to start, but 
poller thread called GetOverlappedResult anyway causing the situation 
described here: 
https://blogs.msdn.microsoft.com/oldnewthing/20110303-00/?p=11313

The patch tries to detect such situation and avoid calling 
GetOverlappedResult.

> Also, it's normal for changes like this to
> bake in the main line for a bit before back porting to 8u.

Problem is windows-only and we don't have jdk9 windows builds at Red Hat 
so can test only with jdk8.

-- 
-Alex