Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 17 Feb 2012 05:25:59 +0000 (UTC)
From: "Shai Erera (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <576795577.49647.1329456359569.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <296779272.33045.1329162419690.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (LUCENE-3776) NRTManager shouldn't expose its
 private SearcherManager
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-3776?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D132=
10064#comment-13210064 ]=20

Shai Erera commented on LUCENE-3776:
------------------------------------

bq. Hang on =E2=80=93 SM now takes either IW or Director

You're right, I missed that. For some reason I had the impression it takes =
an IR, which is obviously wrong, since it won't be allowed to close it.

bq. do you mean the SearcherFactory could make some other reader

I'm less worried about that. We give SF an IndexReader, I can only expect t=
hat it will return an IndexSearcher on top of it. Maybe we can assert that =
IndexSearcher.getIndexReader =3D=3D newReader in refreshIfNeeded?

bq. I think there's no way a non-DirReader can get into NRTManager=20

You're right. If you keep the assert, maybe add a nice msg to it?

bq. I didn't yet add a hard check for an evil SearcherFactory...

I think that's ok to assume that SearcherFactory is not evil. Maybe the ass=
ert I suggested above would be enough?
               =20
> NRTManager shouldn't expose its private SearcherManager
> -------------------------------------------------------
>
>                 Key: LUCENE-3776
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3776
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Blocker
>             Fix For: 3.6, 4.0
>
>         Attachments: LUCENE-3776.patch, LUCENE-3776.patch
>
>
> Spinoff from LUCENE-3769.
> To actually obtain an IndexSearcher from NRTManager, it's a 2-step proces=
s now.
> You must .getSearcherManager(), then .acquire() from the returned Searche=
rManager.
> This is very trappy... because if the app incorrectly calls maybeReopen o=
n that private SearcherManager (instead of NRTManager.maybeReopen) then it =
can unexpectedly cause threads to block forever, waiting for the necessary =
gen to become visible.  This will be hard to debug... I don't like creating=
 trappy APIs.
> Hopefully once LUCENE-3761 is in, we can fix NRTManager to no longer expo=
se its private SM, instead subclassing ReferenceManaager.
> Or alternatively, or in addition, maybe we factor out a new interface (Se=
archerProvider or something...) that only has acquire and release methods, =
and both NRTManager and ReferenceManager/SM impl that, and we keep NRTManag=
er's SM private.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira

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