Could we get the Channel (and other necessary classes) implementation from 
Apache Harmony and provide our own implementation?  Not ideal, but may solve 
the problem until it can be resolved by other means.

Just a thought, I haven't looked into Harmony's implementation to know whether 
that is viable or not.

-Grant


On Jan 28, 2010, at 8:24 AM, Michael McCandless wrote:

> Bummer.
> 
> So the only viable workarounds are 1) don't use Thread.interrupt (nor,
> things like Future.cancel, which in turn use Thread.interrupt) with
> NIOFSDir, or 2) we fix NIOFSDir to reopen the channel AND the app must
> make a deletion policy that keeps a commit alive if any reader is
> using it.  Or, 3) don't use NIOFSDir!
> 
> Mike
> 
> On Thu, Jan 28, 2010 at 7:29 AM, Simon Willnauer
> <simon.willna...@googlemail.com> wrote:
>> On Thu, Jan 28, 2010 at 12:43 PM, Michael McCandless
>> <luc...@mikemccandless.com> wrote:
>>> On Thu, Jan 28, 2010 at 6:38 AM, Uwe Schindler <u...@thetaphi.de> wrote:
>>> 
>>>> So I checked the code of NIOFSIndexInput, my last comment was not really 
>>>> correct:
>>>> NIOFSIndexInput extends SimpleFSIndexInput and that opens the RAF. In the 
>>>> ctor RAF.getChannel() is called. The RAF keeps open until the file is 
>>>> closed (and also the channel).
>>>> 
>>>> So it's really simple to fix in my opinion, just call getChannel() again 
>>>> on this exception. Because the RAF should still be open?
>> 
>> Short answer:
>>  public final FileChannel getChannel() {
>>        synchronized (this) {
>>            if (channel == null)
>>                channel = FileChannelImpl.open(fd, true, rw, this);
>>            return channel;
>>        }
>>    }
>> 
>> this is not gonna work I tried it before. The RandomAccessFile buffers
>> the channel!!
>> 
>> simon
>>> 
>>> I think we need a definitive answer on what happens to the RAF when
>>> the FileChannel was closed by Thread.Interrupt.  Simon can you test
>>> this?
>>> 
>>> Mike
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to