Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] nio exception

On 03/07/2012 03:32 AM, Shawn Pearce wrote:
> On Tue, Mar 6, 2012 at 05:16, Markus Duft <markus.duft@xxxxxxxxxx> wrote:

>> any thoughts? i happened to get this for reads of the .git/config file previously sporadically since 1.1,
> I didn't realize the config file reader used NIO either. I thought
> that was a simple FileInputStream.

Yeah, it does use the stream. the code looks like this:

final FileInputStream in = new FileInputStream(path);
try {
	final long sz = in.getChannel().size();

problematic here is the in.getChannel().size()... this uses a NIO channel to determine the size of the file (lol). This is the step that can fail. I'm not really sure what would be the best solution here, but i think a simple "final long sz = path.length();" would do instead. or is File.length() somehow bad? or more bad than Channel.size()?

i prepared a change [1], and pushed it to gerrit, maybe you want to have a look...? I ran all unit tests and started an egit instance with this change - my workspace behaves as usual, and no errors occur (although this doesn't mean anything :D).



>> but now it also happened for the stash feature (which is new for me - i fetched from the repos today).
> Ick. JGit as a library really cannot rely on using NIO, or needs to be
> more careful where it is used. If the embedding application sends an
> interrupt to a thread that JGit has doing file IO using NIO, JGit
> needs to be prepared for the file being closed as the interrupt is
> delivered. One can argue that at least delivering the interrupt
> instead of doing the requested IO operation is the right behavior, as
> its likely the user has requested the operation to cancel (IIRC
> Eclipse sends an interrupt on the cancel/stop button in a progress
> bar) so doing more IO is maybe not a good idea. But closing the file
> handle automatically like NIO does is really evil.

Back to the top