Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 23341 invoked from network); 2 May 2010 23:48:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 May 2010 23:48:02 -0000 Received: (qmail 78483 invoked by uid 500); 2 May 2010 23:48:00 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 78442 invoked by uid 500); 2 May 2010 23:48:00 -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 78435 invoked by uid 99); 2 May 2010 23:48:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 May 2010 23:48:00 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of markrmiller@gmail.com designates 74.125.82.176 as permitted sender) Received: from [74.125.82.176] (HELO mail-wy0-f176.google.com) (74.125.82.176) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 May 2010 23:47:56 +0000 Received: by wyb33 with SMTP id 33so1417940wyb.35 for ; Sun, 02 May 2010 16:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=vcLWDVZl8Fe6mE2ST11mxHCbMyuAsx6athAJQc0kDK4=; b=UJElwAbXE2Qn8dB5/Dq/hmYO6z/k1dytDq+uVbr7SHBA2QjK+Zv4TjLDQUMNpryeBy 9q/hMBYP21PxCpznk+1lEgOlVpjXRva8I/xucuET7G5UW1ewCvXMdyBCF6o18VFBbCdS So2/pcMQC8p2PFsREJzv/SgyPgLKBGQcDU1bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=ARByJoAyD5XRoKcsvEJe+M6CItvrQAq3vrymtrQWnXa/paNE04g9SduyXbhjE1P1rV Aq3mB4XeUXBuigJPDg37UgIk7yIzGduvjDIS3QMq5hoJPzCMme9jTqUAbuOTs4YviFdE iJAjooL7Il71WpM0CmIwIennbt+cb0cQaaMkI= MIME-Version: 1.0 Received: by 10.216.90.202 with SMTP id e52mr1027558wef.150.1272844054453; Sun, 02 May 2010 16:47:34 -0700 (PDT) Received: by 10.216.165.10 with HTTP; Sun, 2 May 2010 16:47:34 -0700 (PDT) Reply-To: markrmiller@gmail.com In-Reply-To: References: <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 19:47:34 -0400 Message-ID: Subject: Re: Nasty NIO behavior makes NIOFSDirectory silently close channel From: Mark Miller To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary=0016e6d7ee57b861140485a519d9 --0016e6d7ee57b861140485a519d9 Content-Type: text/plain; charset=ISO-8859-1 Interesting ... whats the OS? On Sun, May 2, 2010 at 7:12 PM, John Wang wrote: > 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 >> >> > -- - Mark http://www.lucidimagination.com --0016e6d7ee57b861140485a519d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting ... whats the OS?

On Sun, May= 2, 2010 at 7:12 PM, John Wang <john.wang@gmail.com> wrote:
12 concurrent search threads in a stress environment. (with about 5M doc in= dex)

-John

<= div>
On Sun, May 2, 2010 at 3:13 PM, Mark Miller <markrmiller@gmail.com> wrote:
Perfectly safe to use SimpleFSDirectory. When you measure the performance= , are you measuring a lot of concurrent requests? That's where you shou= ld 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<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<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<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>


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





--
- Mark

http://www.lucidimagination.com
--0016e6d7ee57b861140485a519d9--