JDK Bug# 8079620 (Watch Service Deadlock on OSX)

Christopher Brown christopherbrown06 at gmail.com
Fri Aug 7 11:45:58 UTC 2015


Is there any news concerning a native implementation of the WatchService
(using native notifications instead of polling) for Mac OS X ?  For
example, is it planned for JDK9 ?


On 7 August 2015 at 13:36, Vinay Purohit <vp at cloudjunxion.com> wrote:

> 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> 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. 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
> 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/. 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/01e9d122/attachment-0001.html>

More information about the nio-dev mailing list