Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 20684 invoked from network); 2 May 2010 23:13:18 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 May 2010 23:13:18 -0000 Received: (qmail 64181 invoked by uid 500); 2 May 2010 23:13:17 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 64099 invoked by uid 500); 2 May 2010 23:13:17 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 64092 invoked by uid 99); 2 May 2010 23:13:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 May 2010 23:13:17 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of john.wang@gmail.com designates 209.85.221.171 as permitted sender) Received: from [209.85.221.171] (HELO mail-qy0-f171.google.com) (209.85.221.171) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 May 2010 23:13:09 +0000 Received: by qyk1 with SMTP id 1so2841387qyk.5 for ; Sun, 02 May 2010 16:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=7SnwdSKSYQwxdP/K14oWYzKFjrBx5Sv2jI8iVpomD30=; b=FyfrcZ7H4J+sABAdF9lVQDYeRlDOB6RFIPQECfCcFbd1Z3S9shSVc+WuQTSbiaB8A2 8/eBDnvwCLEFRM2B+jijC2Diy0cHSn6xWCLa1ysOMk6mQq8guUkTfLOj5Maww4alX0Vc dPZ1V3q9Z1azWqa2vuYTtHOnY+RgoYxO5aX9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mnTbIYcrirSRyAk34aGf6DdDOu5UH0zo++kOZzlr+lcLqetWzZbXV1H8j3BVUI8kC6 v1e7SHqS4r/jL827ToixVRULfqFvJLkT8Lxk8YwxD4C5uCOjNNao3TIH5s7LQHiIY3yG FkRGAO8KHtnrV/k2Q9/0v1HMEErO6Wh3RRowg= MIME-Version: 1.0 Received: by 10.229.228.148 with SMTP id je20mr161072qcb.31.1272841967968; Sun, 02 May 2010 16:12:47 -0700 (PDT) Received: by 10.229.225.3 with HTTP; Sun, 2 May 2010 16:12:47 -0700 (PDT) In-Reply-To: <4BDDF8EF.8040700@gmail.com> References: <000901caa00e$6c538680$44fa9380$@de> <9ac0c6aa1001280343m3449a542kc6b2dea5d1c6aa23@mail.gmail.com> <9ac0c6aa1001280524t4ce21010ta6f00a94a44a9864@mail.gmail.com> <85d3c3b61001291100n4fe0fa33v2da129d94d5d1e1e@mail.gmail.com> <9ac0c6aa1001291103m4b8b410q309df938fbb173c2@mail.gmail.com> <4B6337BE.1080701@gmail.com> <4BDDF8EF.8040700@gmail.com> Date: Sun, 2 May 2010 16:12:47 -0700 Message-ID: Subject: Re: Nasty NIO behavior makes NIOFSDirectory silently close channel From: John Wang To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary=00163630f6095b24260485a49d85 X-Virus-Checked: Checked by ClamAV on apache.org --00163630f6095b24260485a49d85 Content-Type: text/plain; charset=ISO-8859-1 12 concurrent search threads in a stress environment. (with about 5M doc index) -John On Sun, May 2, 2010 at 3:13 PM, Mark Miller wrote: > Perfectly safe to use SimpleFSDirectory. When you measure the performance, > are you measuring a lot of concurrent requests? That's where you should see > the win. > > - Mark > > > On 5/1/10 6:38 PM, John Wang wrote: > >> We are seeing this issue as well in your production. (using Zoie on top >> of lucene 2.9.1) >> After some performance comparisons, we do NOT see performance gain with >> NIO, rather these nasty ClosedChannelExceptions. >> >> I think the performance gains ppl are seeing with 2.9.1 can be due to >> many different things. From what we seen, they are not related to >> NIOFSDirectory. >> >> Our solution is to avoid calling FSDirectory.open(), instead just call >> new SimpleFSDirectory(). Is this safe? >> >> -John >> >> On Fri, Jan 29, 2010 at 12:32 PM, Mark Miller > > wrote: >> >> Perhaps - one of the things they are supposed to be addressing is >> extendability. >> >> nio2 does have FileSystemProvider, which would actually allow you to >> create a custom channel ! >> >> I have not dug in enough to know much more than that though. >> >> *But*, another really interesting thing is that in Java 7, >> FileDescriptors are ref counted ! (though users can't inc/dec). >> >> But, FileInputStream and OutputStream have a new constructor that takes >> a FileDescriptor. >> >> So possibly, you could just make one that sits around to keep the >> FileDescriptor valid, and get your channel off >> FileInputStream/FileOutputStream? >> >> And then if it goes down, make a new one using the FileDescriptor which >> was not actually closed because there was a still a ref to it. >> >> Possibly .... ;) >> >> Michael McCandless wrote: >> > Does anyone know if nio2 has improved this...? >> > >> > Mike >> > >> > On Fri, Jan 29, 2010 at 2:00 PM, Jason Rutherglen >> > > >> >> 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 >> >> > >> >> 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 >> >>> > > wrote: >> >>> >> >>>> On Thu, Jan 28, 2010 at 12:43 PM, Michael McCandless >> >>>> > >> >> wrote: >> >>>> >> >>>>> On Thu, Jan 28, 2010 at 6:38 AM, Uwe Schindler >> > 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-unsubscribe@lucene.apache.org >> >> >> >>>>> For additional commands, e-mail: >> java-dev-help@lucene.apache.org > java-dev-help@lucene.apache.org> >> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> >> >> >>>> For additional commands, e-mail: >> java-dev-help@lucene.apache.org > java-dev-help@lucene.apache.org> >> >> >>>> >> >>>> >> >>>> >> >>> >> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> >> >> >>> For additional commands, e-mail: >> java-dev-help@lucene.apache.org > java-dev-help@lucene.apache.org> >> >> >>> >> >>> >> >>> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> >> >> >> For additional commands, e-mail: java-dev-help@lucene.apache.org >> >> >> >> >> >> >> >> >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> >> >> > For additional commands, e-mail: java-dev-help@lucene.apache.org >> >> >> > >> > >> >> >> -- >> - Mark >> >> http://www.lucidimagination.com >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> >> >> For additional commands, e-mail: java-dev-help@lucene.apache.org >> >> >> >> > > -- > - Mark > > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org > > --00163630f6095b24260485a49d85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 12 concurrent search threads in a stress environment. (with about 5M doc in= dex)

-John

On Sun= , May 2, 2010 at 3:13 PM, Mark Miller <markrmiller@gmail.com> wrote:
Perfectly safe to use SimpleFSDirectory. Wh= en you measure the performance, are you measuring a lot of concurrent reque= sts? That's where you should see the win.

- Mark


On 5/1/10 6:38 PM, John Wang wrote:
We are seeing this issue as well in your production. (using Zoie on top
of lucene 2.9.1)
After some performance comparisons, we do NOT see performance gain with
NIO, rather these nasty ClosedChannelExceptions.

I think the performance gains ppl are seeing with 2.9.1 can be due to
many different things. From what we seen, they are not related to
NIOFSDirectory.

Our solution is to avoid calling FSDirectory.open(), instead just call
new SimpleFSDirectory(). Is this safe?

-John

On Fri, Jan 29, 2010 at 12:32 PM, Mark Miller <markrmiller@gmail.com
<mailto:markr= miller@gmail.com>> wrote:

=A0 =A0Perhaps - one of the things they are supposed to be addressing is =A0 =A0extendability.

=A0 =A0nio2 does have FileSystemProvider, which would actually allow you t= o
=A0 =A0create a custom channel !

=A0 =A0I have not dug in enough to know much more than that though.

=A0 =A0*But*, another really interesting thing is that in Java 7,
=A0 =A0FileDescriptors are ref counted ! (though users can't inc/dec).=

=A0 =A0But, FileInputStream and OutputStream have a new constructor that t= akes
=A0 =A0a FileDescriptor.

=A0 =A0So possibly, you could just make one that sits around to keep the =A0 =A0FileDescriptor valid, and get your channel off
=A0 =A0FileInputStream/FileOutputStream?

=A0 =A0And then if it goes down, make a new one using the FileDescriptor w= hich
=A0 =A0was not actually closed because there was a still a ref to it.

=A0 =A0Possibly .... ;)

=A0 =A0Michael McCandless wrote:
=A0 =A0 > Does anyone know if nio2 has improved this...?
=A0 =A0 >
=A0 =A0 > Mike
=A0 =A0 >
=A0 =A0 > On Fri, Jan 29, 2010 at 2:00 PM, Jason Rutherglen
=A0 =A0 > <jason.rutherglen@gmail.com <mailto:jason.rutherglen@gmail.com>>= ;

=A0 =A0wrote:
=A0 =A0 >
=A0 =A0 >> Defaulting NIOFSDir could account for some of the recent = speed
=A0 =A0 >> improvements users have been reporting in Lucene 2.9. =A0= So
=A0 =A0removing it
=A0 =A0 >> as a default could reverse those and people could then re= port Lucene
=A0 =A0 >> 3.X has slowed...
=A0 =A0 >>
=A0 =A0 >> On Thu, Jan 28, 2010 at 5:24 AM, Michael McCandless
=A0 =A0 >> <lucene@mikemccandless.com <mailto:lucene@mikemccandless.com>&= gt;

=A0 =A0wrote:
=A0 =A0 >>
=A0 =A0 >>> Bummer.
=A0 =A0 >>>
=A0 =A0 >>> So the only viable workarounds are 1) don't use =A0 =A0Thread.interrupt (nor,
=A0 =A0 >>> things like Future.cancel, which in turn use Thread.i= nterrupt) with
=A0 =A0 >>> NIOFSDir, or 2) we fix NIOFSDir to reopen the channel= AND the
=A0 =A0app must
=A0 =A0 >>> make a deletion policy that keeps a commit alive if a= ny reader is
=A0 =A0 >>> using it. =A0Or, 3) don't use NIOFSDir!
=A0 =A0 >>>
=A0 =A0 >>> Mike
=A0 =A0 >>>
=A0 =A0 >>> On Thu, Jan 28, 2010 at 7:29 AM, Simon Willnauer
=A0 =A0 >>> <simon.willnauer@googlemail.com
=A0 =A0<mailto:simon.willnauer@googlemail.com>> wrote:
=A0 =A0 >>>
=A0 =A0 >>>> On Thu, Jan 28, 2010 at 12:43 PM, Michael McCandl= ess
=A0 =A0 >>>> <lucene@mikemccandless.com <mailto:lucene@mikemccandless.com>>

=A0 =A0wrote:
=A0 =A0 >>>>
=A0 =A0 >>>>> On Thu, Jan 28, 2010 at 6:38 AM, Uwe Schindle= r
=A0 =A0<uwe@thetap= hi.de <mailto:u= we@thetaphi.de>> wrote:
=A0 =A0 >>>>>
=A0 =A0 >>>>>
=A0 =A0 >>>>>> So I checked the code of NIOFSIndexInput,= my last comment
=A0 =A0was not really correct:
=A0 =A0 >>>>>> NIOFSIndexInput extends SimpleFSIndexInpu= t and that opens
=A0 =A0the RAF. In the ctor RAF.getChannel() is called. The RAF keeps open=
=A0 =A0until the file is closed (and also the channel).
=A0 =A0 >>>>>>
=A0 =A0 >>>>>> So it's really simple to fix in my op= inion, just call
=A0 =A0getChannel() again on this exception. Because the RAF should still<= br> =A0 =A0be open?
=A0 =A0 >>>>>>
=A0 =A0 >>>> Short answer:
=A0 =A0 >>>> =A0public final FileChannel getChannel() {
=A0 =A0 >>>> =A0 =A0 =A0 =A0synchronized (this) {
=A0 =A0 >>>> =A0 =A0 =A0 =A0 =A0 =A0if (channel =3D=3D null) =A0 =A0 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0channel =3D FileCh= annelImpl.open(fd, true, rw, this);
=A0 =A0 >>>> =A0 =A0 =A0 =A0 =A0 =A0return channel;
=A0 =A0 >>>> =A0 =A0 =A0 =A0}
=A0 =A0 >>>> =A0 =A0}
=A0 =A0 >>>>
=A0 =A0 >>>> this is not gonna work I tried it before. The Ran= domAccessFile
=A0 =A0buffers
=A0 =A0 >>>> the channel!!
=A0 =A0 >>>>
=A0 =A0 >>>> simon
=A0 =A0 >>>>
=A0 =A0 >>>>> I think we need a definitive answer on what h= appens to the
=A0 =A0RAF when
=A0 =A0 >>>>> the FileChannel was closed by Thread.Interrup= t. =A0Simon can
=A0 =A0you test
=A0 =A0 >>>>> this?
=A0 =A0 >>>>>
=A0 =A0 >>>>> Mike
=A0 =A0 >>>>>
=A0 =A0 >>>>>
=A0 =A0-------------------------------------------------------------------= --
=A0 =A0 >>>>> To unsubscribe, e-mail:
=A0 =A0java-dev-unsubscribe@lucene.apache.org
=A0 =A0<mailto:java-dev-unsubscribe@lucene.apache.org>

=A0 =A0 >>>>> For additional commands, e-mail:
=A0 =A0java-dev-help@lucene.apache.org <mailto:java-dev-help@lucene.apache.org<= /a>>

=A0 =A0 >>>>>
=A0 =A0 >>>>>
=A0 =A0 >>>>>
=A0 =A0 >>>>
=A0 =A0-------------------------------------------------------------------= --
=A0 =A0 >>>> To unsubscribe, e-mail: java-dev-unsubscribe@luc= ene.apache.org
=A0 =A0<mailto:java-dev-unsubscribe@lucene.apache.org>

=A0 =A0 >>>> For additional commands, e-mail:
=A0 =A0java-dev-help@lucene.apache.org <mailto:java-dev-help@lucene.apache.org<= /a>>

=A0 =A0 >>>>
=A0 =A0 >>>>
=A0 =A0 >>>>
=A0 =A0 >>>
=A0 =A0-------------------------------------------------------------------= --
=A0 =A0 >>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.= apache.org
=A0 =A0<mailto:java-dev-unsubscribe@lucene.apache.org>

=A0 =A0 >>> For additional commands, e-mail:
=A0 =A0java-dev-help@lucene.apache.org <mailto:java-dev-help@lucene.apache.org<= /a>>

=A0 =A0 >>>
=A0 =A0 >>>
=A0 =A0 >>>
=A0 =A0 >>
=A0 =A0-------------------------------------------------------------------= --
=A0 =A0 >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apac= he.org
=A0 =A0<mailto:java-dev-unsubscribe@lucene.apache.org>

=A0 =A0 >> For additional commands, e-mail: java-dev-help@lucene.apache.or= g
=A0 =A0<mailto:java-dev-help@lucene.apache.org>

=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >
=A0 =A0 > -------------------------------------------------------------= --------
=A0 =A0 > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.o= rg
=A0 =A0<mailto:java-dev-unsubscribe@lucene.apache.org>

=A0 =A0 > For additional commands, e-mail: java-dev-help@lucene.apache.org
=A0 =A0<mailto:java-dev-help@lucene.apache.org>

=A0 =A0 >
=A0 =A0 >


=A0 =A0--
=A0 =A0- Mark

=A0 =A0http:= //www.lucidimagination.com




=A0 =A0-------------------------------------------------------------------= --
=A0 =A0To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org=
=A0 =A0<mailto:java-dev-unsubscribe@lucene.apache.org>

=A0 =A0For additional commands, e-mail: java-dev-help@lucene.apache.org
<= /div> =A0 =A0<mailto:java-dev-help@lucene.apache.org>




--
- Mark

http://www.lu= cidimagination.com

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


--00163630f6095b24260485a49d85--