Does anyone know if nio2 has improved this...?
Mike
On Fri, Jan 29, 2010 at 2:00 PM, Jason Rutherglen
<jason.rutherg...@gmail.com> wrote:
> Defaulting NIOFSDir could account for some of the recent speed
> improvements users have been reporting in Lucene 2.9. So removing it
> as a default could reverse those and people could then report Lucene
> 3.X has slowed...
>
> On Thu, Jan 28, 2010 at 5:24 AM, Michael McCandless
> <luc...@mikemccandless.com> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
