NIO feedback

[Alan Bateman]

[ John and I exchanged a few mails offline on this and John has being 
trying out a quick prototype [1] that I hacked up to check the 
usefulness of this. ]

John Hendrikx wrote:
> :
>
> I've been running it against jdk7 b74, freshly downloaded, and it 
> seems to work as expected.  My observations:
>
> - I get progress feedback roughly twice a second
The interval is currently 200ms so it could be up to 5 times a second. 
Clearly this is something that could be configurable but it is a fixed 
interval for now to keep it simple.

>
> - Sometimes the feedback has the same values for several calls in a 
> row (due to some OS filesystem contention I'm pretty sure).  This is 
> good as it allows me to abort at any time.
Right, this is likely wait for I/O or the network (or in theory a 
sampling glitch as the transfer progress is sampled without 
synchronization - if an out-of-range value is sampled then it is dropped 
and the previous "good" value is reported to the progress method).

>
> - After aborting a Copy by returning false, I still get several 
> feedback calls (10+ on large files) with constant 'bytetransferred' 
> values.  I assume this is due to the deletion occuring.  I keep 
> returning "false" for these, don't know what would happen if I 
> "change" my mind so to speak :)
The cancellation is done cooperatively (for feasibility reasons) and 
might not be instantaneous. Also, as you noted, it does attempt to 
recover and remove the target if partially created. The copyTo method 
does not complete until this is done and progress events will continue 
to be reported. Another approach would have been to discontinue events 
after "false" has been returned.

>
> - File was properly removed after an aborted Copy.
Yes but cannot be guaranteed - say you are copying to a remote file 
system and the network connection is lost.

>
> - After integrating it in my project, I tested copying a few 1000's of 
> files and it behaved as expected (the code actually does a verify 
> after copying and no anomalies were detected).
Good.

>
> The only thing I couldn't do that my own version could was throttling 
> and pausing of the copy process.  Those are very specific needs though 
> and I doubt they'd be of much value as standard features -- currently 
> I'd lean to just removing those features in favor of using a standard 
> copy function (which handles the nasty details of copying attributes 
> as well).  I did however test what happened if you slowed down the 
> ProgressMonitor callback considerably, but the copy continued 
> unimpeded (as I would have expected).
Throttling and pausing are a bit beyond what the default provider should 
be expected to support.  A "desktop" provider or a provider that 
supports access to files over http or very remote file systems. As 
regards the observation that the copy is not impacted by the progress 
method - you are right, as they copy runs in the background when this 
option is used.

-Alan.

[1] 
http://cr.openjdk.java.net/~alanb/6892923/ExtendedCopyOption.ProgressMonitor.html