WatchService questions

[Alan Bateman]

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.