WatchService questions

[Sebastian Sickelmann]

Alan Bateman wrote:
> Sebastian Sickelmann wrote:
> > :
> > 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
> >   
> The watch service implementations that makes use of kernel support 
> always process and queues the events in the order that they are 
> received. The polling implementation (used when there isn't kernel 
> support) processes snapshots of the directory and so cannot infer the 
> order of changes between snapshots.
So a user of the WatchService-API cannot count in the order of the events. Or is there a way to ask the FileSystem or the Watch-Service if it makes use of kernel support. Maybe this would be a usefull method(isPolling() or isNative()) in WatchService. Maybe a Method(isOrderGuaranteed) in WatchService to evaluate if the order is guaranteed is usefull too.

> It's okay for several entities 
> (maybe threads in the same VM, maybe other programs or processes) to be 
> creating or changing files at the same time. It does reduce the 
> likelihood of repeated modification events to the same file and so the 
> representation will be less efficient. You can't re-order create or 
> delete events as otherwise the application's view of the directory will 
> get out of sync.
I have overseen this fact and i think you are right.
While searching for the last MODIFY the implementation should stop searching after Events like CREATE and DELETE.
Here an example: newest to oldest events.
9- MODIFY File3
8- MODIFY File2
7- CREATE File2
6- CREATE File1
5- DELETE File1
4- MODIFY File1
3- CREATE File3
2- CREATE File2
1- CREATE File1

An Update to File3 should increase the modification count of Event 9
An Update to File2 should increase the modification count of Event 8
An Update to File1 should not increase the modification count of Event 4 because there are CREATE and DELETE Events at Event 5,6 and 7. A Event 10(MODIFY File1) should be inserted instead.

> It may be useful in some cases to know when a file was 
> modified relative to other operations - I think you are proposing to not 
> do this, is that right?
I think that you understand my proposal correct. See Example above.
I think also that the relative Position of MODIFY to other operations is interesting, but not to other Events (in particular other MODIFY-Events)on other Files.

I can imagine a case where the order of concurrent Modification of different files would be interessting. But only if i get more information(for example the size of change the change, or which attribute has changed) in the modify-event. But i only get the modification count. Example:

4- MODIFY File2 ModCount=3 
3- MODIFY File1 ModCount=2
2- MODIFY File2 ModCount=5
1- MODIFY File1 ModCount=7

gives me the same information as

2- MODIFY File2 ModCount=8
1- MODIFY File1 ModCount=9

But 

5- MODIFY File2 ModCount=3 
4- MODIFY File1 ModCount=2
3- CREATE File3 ModCount=1
2- MODIFY File2 ModCount=5
1- MODIFY File1 ModCount=7

is not the same as

3- CREATE File3 ModCount=1
2- MODIFY File2 ModCount=8
1- MODIFY File1 ModCount=9


> I looked at the test you attached but it doesn't 
> seem to demonstrate a problem (or at least I don't see it on the first 
> glance).
The test writes 64 Files in parallel(each in 16 Steps). If the order of MODIFY Events on different Files is not relevant(see above), than there should be 128 Events in the Event List (64 CREATE with ModCount 1 and 64 MODIFY with ModCount 16).

But because in the actual implementation the order of MODIFY Events on different Files seems to be relevant, it generates many more "unnecessary" Events. This leeds to earlier OVERFLOW Events which forces me to rescan the Directory again. 
> 
> -Alan.
- Sebastian
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser