WatchService - Exposing more of the Inotify Event Model

[Benedict Elliott Smith]

While on the topic of the WatchService API, I wonder if there are any plans
to modify the WatchKey to include a method for retrieving the object/path it
is watching. The fact that it does not introduces a race condition, whereby
the WatchService can return a WatchKey before the thread registering the key
has a chance to put the key in a map containing this information.



On 23 September 2010 07:41, fm <fudmail at gmail.com> wrote:

> I've modified a few of the WatchService implementation classes to
> allow for the registration of additional WatchEvent.Kind instances
> that represent the native events of the underlying OS platform. I
> believe the changes add flexibility to the WatchService API, with
> minimal disruptive code changes to the existing implementation. There
> should be a negligible impact on the existing performance. I have
> altered the implementation of the LinuxWatchService to support the
> additional event model; however, the SolarisWatchService and
> WindowsWatchService implementations are effectively unchanged and
> should work the same as before. Similar modifications could be made to
> these WatchService implementations to also expose their native event
> models.
>
> I am completely open to hearing comments on if this type of added
> flexibility to the WatchService API is appropriate for the JDK 7 or
> better left to an ex
> ternal project.
>
> I will gladly provide the source code files for evaluation if there is
> interest. Modified files are AbstractWatchKey.java,
> AbstractPoller.java, LinuxWatchService.java, and one new file
> LinuxWatchEventKind.java.
>
> Regards
>
> On Thu, Sep 2, 2010 at 10:59 AM, fm <fudmail at gmail.com> wrote:
> > Thank you for the response. This is the type of info I was looking
> > for. Reading the WatchService related API documentation I got the
> > sense it was designed for extension. After skimming over some of the
> > related source code, it wasn't yet clear to me the best way to go
> > about accessing the additional Linux specific filesystem events. After
> > looking at the JDK7 source code it was clear to me a lot of hard work
> > went into the design of the WatchService notification capability and
> > it would be a shame not to be able to leverage it for accessing
> > additional event tyeps.  I will look into you suggestions.
> >
> > I am also aware that Inotify's IN_CLOSE_WRITE event is not the silver
> > bullet to my particular project--but as the link Rémi provided points
> > out, it may be more suitable that IN_MODIFY (in my case as well as
> > others). But I believe you are correct also that one cannot assume
> > something else does not have a file open for writing...it is just much
> > more unlikely in my particular case.
> >
> > Regards
> >
> >
> > On Thu, Sep 2, 2010 at 8:00 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >> f m wrote:
> >>>
> >>> Per Alan B.'s request, I'm moving a discussion here that was started at
> >>> http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0
> >>> <http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0>
> >>>
> >>> I'll try to summarize.
> >>>
> >>> A useful goal of the JDK7 WatchService is to provide a uniform file
> system
> >>> event facility across multiple operating systems. However, in some
> cases, it
> >>> may be more desirable to give up the portability in order to tap into
> the
> >>> full expressiveness of the event model of the native OS. For example,
> >>> Inotify on the Linux platform provides additional events not currently
> used
> >>> by the LinuxWatchService implementation such as: IN_ACCESS,
> IN_CLOSE_WRITE,
> >>> IN_CLOSE_NO_WRITE, and IN_OPEN.
> >>>
> >>> I gave one example at the above URI where an event like IN_CLOSE_WRITE
> >>> could be used to detect and process a large file only after it has been
> >>> completely copied into a watch directory.
> >>>
> >>> After looking over the internal LinuxWatchService.java source code, it
> >>> appears that the implementation could be readily used (modified or
> resused?)
> >>> to also provide access to these additional event types. Another event
> class
> >>> representation like LinuxWatchEventKinds would need to be added and
> used
> >>> alternatively to the StandardWatchEventKinds.
> >>>
> >>> My question. Would extending the LinuxWatchService capability to
> >>> optionally expose the greater set of Inotify event types be in scope
> for JDK
> >>> 7 development, or will client developers who desire this capability
> need to
> >>> find 3rd party implementations (or develop it themselves)?
> >>>
> >>> Regards.
> >>>
> >> The API is designed to allow for events and modifiers that are defined
> >> beyond the javadoc so provider implementations can include support for
> other
> >> events if they wish. We haven't included any support for other events in
> the
> >> JDK because our primary motive has been to help the performance of
> >> applications that are forced to poll the file system today. If you are
> >> looking for pointers then there is one implementation specific modifier
> >> (com.nio.file.ExtendedWatchEvent)  that might help show you how
> additional
> >> support is included. You are welcome to hack on the code and try out
> >> additional events but you have to be a contributer to contribute patches
> >> [1].  A small comment on the "close after write" event is that I don't
> think
> >> you are guaranteed that the file isn't being modified by other entities.
> >> That might not be a concern in your environment but just mentioning it.
> >>
> >> -Alan.
> >>
> >> [1] http://openjdk.java.net/contribute/
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100923/457f599b/attachment.html