Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 11 Sep 2012 02:54:07 +1100 (NCT)
From: "Robert Muir (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <1842938384.58289.1347292447806.JavaMail.jiratomcat@arcas>
In-Reply-To: <1227316061.58001.1347288368006.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (LUCENE-4372) CachingCollector.create(boolean,
 boolean, double) is trappy
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-4372?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D134=
52095#comment-13452095 ]=20

Robert Muir commented on LUCENE-4372:
-------------------------------------

{quote}
CachingCollector is an optimization. If you can spare 10 MB of cache, and y=
ou happen to execute queries that answer #documents that can be cached with=
in that limit, then as in the case Yonik describes, you can execute the que=
ry once, collect the docs (by a real Collector) and cache them (CachingColl=
ector) in order to replay to another Collector. If there wasn't enough RAM,=
 you cannot use replay() (you'll hit IllegalStateEx).
{quote}

Right but then when we run out of cache, shouldnt we dumping the existing c=
ache to the underlying collector first? What am I missing?

it seems to me we just throw away the cache completely and then start colle=
cting, thats why it doesnt make a lot of sense to me:

{noformat}
          if (nextLength <=3D 0) {
            // Too many docs to collect -- clear cache
            curDocs =3D null;
            cachedSegs.clear();
            cachedDocs.clear();
            other.collect(doc);
            return;
          }
{noformat}


               =20
> CachingCollector.create(boolean, boolean, double) is trappy
> -----------------------------------------------------------
>
>                 Key: LUCENE-4372
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4372
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Robert Muir
>
> Followup to LUCENE-3102.
> Shai proposed a method that just caches all scores so they can be replaye=
d:
> {quote}
> Do you think we can modify this Collector to not necessarily wrap another=
 Collector? We have such Collector which stores (in-memory) all matching do=
c IDs + scores (if required). Those are later fed into several processes th=
at operate on them (e.g. fetch more info from the index etc.). I am thinkin=
g, we can make CachingCollector optionally wrap another Collector and then =
someone can reuse it by setting RAM limit to unlimited (we should have a co=
nstant for that) in order to simply collect all matching docs + scores.
> {quote}
> But Mike had concerns about the RAM usage:
> {quote}
> I'd actually rather not have the constant =E2=80=93 ie, I don't want to m=
ake
> it easy to be unlimited? It seems too dangerous... I'd rather your
> code has to spell out 10*1024 so you realize you're saying 10 GB (for
> example).
> {quote}
> My concern here is what happens when you dont specify enough, I think tho=
se hits are just silently dropped (which is worse than using lots of RAM).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
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