Alan.Bateman at Sun.COM
Sun Oct 25 14:26:23 PDT 2009
[ John and I exchanged a few mails offline on this and John has being
trying out a quick prototype  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).
> 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.
More information about the nio-dev