JDK Bug# 8079620 (Watch Service Deadlock on OSX)

Vinay Purohit vp at cloudjunxion.com
Fri Aug 7 11:36:38 UTC 2015


Hi Brian,

Thanks for looking into this issue. 

We are able to reproduce the problem by rapidly creating sub-dirs and also registering them - as soon as we detect a CREATE event - with the watch service. The combination of polling (by OS-X) and the added burden of new registrants is usually enough to trigger the issue quickly. Not sure if there’s an easier way that distills it to the bare minimum set of conditions necessary for its manifestation.

Awaiting your findings once you get a response from those previously involved in the investigation.

BR,
Vinay


> On Aug 6, 2015, at 9:17 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hello Vinay,
> 
> On Aug 5, 2015, at 7:37 PM, Vinay Purohit <vp at cloudjunxion.com <mailto:vp at cloudjunxion.com>> wrote:
> 
>> I’m writing to inquire about JDK Bug# 8079620 which appears to be very similar to the issue we are seeing. The resolution of that bug seems unclear.
> 
> It appears unclear to me as well and I have made an inquiry as to the reason for its current status.
> 
>> We see the problem with Java 8 (r45, might be in others as well, not sure) when using the Watch service on a Mac OS X platform. The service is being used for monitoring creation/deletion/modification of files under the folder registered with the Watch service. Unfortunately rapid creation/renaming of subfolders under the registered directory results in a hung thread. The stack trace is shown below:
>> 
>> at sun.nio.fs.PollingWatchService$PollingWatchKey.disable(PollingWatchService.java:296)
>> at sun.nio.fs.PollingWatchService.doPrivilegedRegister(PollingWatchService.java:169)
>> at sun.nio.fs.PollingWatchService.access$000(PollingWatchService.java:45)
>> at sun.nio.fs.PollingWatchService$2.run(PollingWatchService.java:128)
>> at sun.nio.fs.PollingWatchService$2.run(PollingWatchService.java:125)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.nio.fs.PollingWatchService.register(PollingWatchService.java:124)
>> at sun.nio.fs.UnixPath.register(UnixPath.java:897)
>> at myClass.functionFoo (myClass:xyz)    <—— Invoke register() here.
> This indeed looks like the same problem described in https://bugs.openjdk.java.net/browse/JDK-8079620 <https://bugs.openjdk.java.net/browse/JDK-8079620>. I have run the test provided in the description of that issue on Mac OS 10.9.5 using both the official build of JDK 8u40 and my development build of JDK 9. I was not able to reproduce the problem with either version but of course one test run is not a guarantee.
> 
>> The stack trace and other details are also posted on StackOverflow:
>> 
>> http://stackoverflow.com/questions/31780727/java-os-x-watchservice-deadlocks <http://stackoverflow.com/questions/31780727/java-os-x-watchservice-deadlocks>
>> 
>> I’m happy to provide more details or perform more experiments, but would first like to confirm I have reached the right forum for discussing this issue. 
> 
> This is the correct forum for java.nio issues.
> 
> It would be helpful if you were able to provide a standalone test case. It would be even better if you were to file an issue including the test case via this page: http://bugs.java.com/ <http://bugs.java.com/>. This will ensure that the problem will be tracked and addressed in due course. This is especially important if the problem is not in fact a duplicate of JDK-8079620.
> 
> Thanks,
> 
> Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150807/3a85ed9c/attachment.html>


More information about the nio-dev mailing list