WatchService questions

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Tue Jan 5 01:52:18 PST 2010


Alan Bateman wrote:
> John Hendrikx wrote:
> > :
> >
> > What I hadn't realized is that after you receive an OVERFLOW that the 
> > subsequent events will form a cohesive stream of events again which 
> > can be used to update a directory after re-reading it.  It does make 
> > sense to me though to "scan" for the overflow so to speak -- either 
> > that or I would probably expect an implementation of WatchService to 
> > clear all pending events before adding the OVERFLOW.  Not only are the 
> > pending events useless if an overflow occurs, but clearing them would 
> > make room for subsequent events again (if not, you'd be in a permanent 
> > state of overflow...?)
> This is a good point as the watch service could drop all pending events 
> when the limit is reached. Furthermore it can drop all subsequent events 
> while the head is an OVERFLOW event. I'll create a bug to track this - 
> thanks!
> 
> > My original assessment was wrong. The Swing Event thread was not 
> > starved for CPU, but instead was busy handling the WatchService events 
> > in the invokeAndWait part.  This made it seem that the Event thread 
> > was starved for CPU (as other parts of the UI weren't updating 
> > anymore) while it really was consuming the CPU all by itself.
> >
> > In effect, in the time it took me to handle 60 WatchService events, 
> > 513 (512 + Overflow?) more had accumulated, resulting in second long 
> > delays for the UI to become responsive again.
> Thanks for the update. I did a quick test that watches a directory and 
> retrieves all events in a timely manner. Another program creates and 
> deletes 10000 files in the watched directory which I think is what you 
> are doing. The test was on Windows (as I think this is where your UI is 
> at, right?). As expected the watcher didn't consume too many CPU cycles 
> and is barely noticeable. Also, the list of events typically only 
> contain a single event as it can easily keep up with programs creating 
> lots of files (which is a very slow in comparison).  I changed the test 
> to sleep periodically, thus delaying the retrieval of events. In that 
> case, 512 events are queued very quickly, and subsequent events are 
> dropped. Again, the CPU usage is barely noticeable so this concurs with 
> your observation that the time is spent on processing the events.
> 
> Anyway, let us know how your solution goes - your war story may be 
> useful to others.
> 
> -Alan.

While reviewing 6907760 i think i found one problem why John is facing so many Events.

If the Copy of the many files is not done in one Thread (ex. multiple Applications writing to the same directory), AbstractWatchKey will only increase modification count if the context that is changing is the same as the last added to the events-lists.

If i am right, the order of the events is not guaranteed. So AbstractWatchKey could check the whole events-list and increase the modification count. This can only be done if we can find a quick implementation. I got some ideas but not tried it yet.

I add a Testcase that shows the Problem with multiple Threads. You can change SEQUENCIAL to true to see how it works in an non-threaded Environment.

Kind regards
Sebastian
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MultipleWriterThreadShouldNotOverflowWatchService.java
Type: text/x-java
Size: 5072 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100105/46ce845e/attachment.bin 


More information about the nio-dev mailing list