FAQ
Hi

I'd like to extend Lucene's FieldCache such that it will read native values
from a different place (in my case, payloads). That is, instead of iterating
on a field's terms and parsing each String to long (for example), I'd like
to iterate over one term (sort:long, again - an example) and decode each
payload value to long, and store it in the cache. The reason I want to
extend Lucene's FieldCache is because I'd like Lucene to take care of
updating this cache when necessary (such as after reopen for example). This
will allow me to use Lucene's Sort option more easily.

I noticed Sort can be extended by providing a CUSTOM SortField, but that
forces me to create Comparable objects, which is much more expensive than
native longs (40 bytes vs. 8 bytes).

I didn't find a way though to extend FieldCache, or ExtendedFieldCache -->
even though both are extendable, I don't find the place where they're given
as input to TopFieldDocCollector, FieldSortedHitQueue etc. Perhaps I'm
missing it?

I need to do it on top of 2.4.1, but if it's not possible and something was
done in 2.9 (which I missed) in that regard I'd be happy to get a pointer to
that.

Today, I use this payload to implement sorting, which is memory efficient
for very large indexes, but for small indexes I think Lucene's built-in sort
will perform better.

BTW, if it interests anyone, perhaps augmenting Lucene's sort w/ reading
values from a Payload, or doing a complete payload-based-sort, I can work up
a patch ...

Thanks
Shai

Search Discussions

  • Chris Hostetter at Aug 25, 2009 at 5:36 pm
    : I'd like to extend Lucene's FieldCache such that it will read native values
    ...
    : payload value to long, and store it in the cache. The reason I want to
    : extend Lucene's FieldCache is because I'd like Lucene to take care of
    : updating this cache when necessary (such as after reopen for example). This
    : will allow me to use Lucene's Sort option more easily.

    this was my motivation when i opened LUCENE-831, but i promptly got bogged
    down with other shit and had to abandon that issue ...
    Miller/Uwe/McCandles seemed like they were making really cool progress
    with it, but (if i remember correctly) it seems to have gotten into some
    sort of quagmire related to reopen and segment merging -- which led to a
    lot of the current segment based sortinging we have now, which makes most
    of that issue obsolete.

    but we still have hte issue of wanting to provide your own caching
    mechanism -- which at the moment has no solution that i know of.

    : I noticed Sort can be extended by providing a CUSTOM SortField, but that

    i think you're only option is to use a custom Sort which uses your own
    private cache of some kind.

    : I didn't find a way though to extend FieldCache, or ExtendedFieldCache -->
    : even though both are extendable, I don't find the place where they're given
    : as input to TopFieldDocCollector, FieldSortedHitQueue etc. Perhaps I'm
    : missing it?

    you're not missing anything ... a singleton is used, and you can't replace
    the singlton because its' a static on the Interface.

    : BTW, if it interests anyone, perhaps augmenting Lucene's sort w/ reading
    : values from a Payload, or doing a complete payload-based-sort, I can work up
    : a patch ...

    I believe that was always one of Busch's goals with the payload stuff, but
    last time i remember hearing about it he was thinking that rather then
    doing it directly with payloads he wants to skip ahead to use column-stride
    fields ... not sure if he had an implementation in mind yet though.



    -Hoss


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Shai Erera at Aug 27, 2009 at 3:31 am
    Thanks a lot for the response !

    I wanted to avoid two things:
    * Writing the logic that invokes cache-refresh upon IndexReader reload.
    * Write my own TopFieldCollector which uses this cache.

    I guess I don't have any other choice by to write both of them, or try to
    make TFC more "customizable" such that someone can pass in his own
    FieldCachePQ. I'll start w/ my own version and if possible suggest an
    extension to TFC.

    Thanks again,
    Shai

    On Tue, Aug 25, 2009 at 8:36 PM, Chris Hostetter
    wrote:
    : I'd like to extend Lucene's FieldCache such that it will read native
    values
    ...
    : payload value to long, and store it in the cache. The reason I want to
    : extend Lucene's FieldCache is because I'd like Lucene to take care of
    : updating this cache when necessary (such as after reopen for example).
    This
    : will allow me to use Lucene's Sort option more easily.

    this was my motivation when i opened LUCENE-831, but i promptly got bogged
    down with other shit and had to abandon that issue ...
    Miller/Uwe/McCandles seemed like they were making really cool progress
    with it, but (if i remember correctly) it seems to have gotten into some
    sort of quagmire related to reopen and segment merging -- which led to a
    lot of the current segment based sortinging we have now, which makes most
    of that issue obsolete.

    but we still have hte issue of wanting to provide your own caching
    mechanism -- which at the moment has no solution that i know of.

    : I noticed Sort can be extended by providing a CUSTOM SortField, but that

    i think you're only option is to use a custom Sort which uses your own
    private cache of some kind.

    : I didn't find a way though to extend FieldCache, or ExtendedFieldCache
    -->
    : even though both are extendable, I don't find the place where they're
    given
    : as input to TopFieldDocCollector, FieldSortedHitQueue etc. Perhaps I'm
    : missing it?

    you're not missing anything ... a singleton is used, and you can't replace
    the singlton because its' a static on the Interface.

    : BTW, if it interests anyone, perhaps augmenting Lucene's sort w/ reading
    : values from a Payload, or doing a complete payload-based-sort, I can work
    up
    : a patch ...

    I believe that was always one of Busch's goals with the payload stuff, but
    last time i remember hearing about it he was thinking that rather then
    doing it directly with payloads he wants to skip ahead to use column-stride
    fields ... not sure if he had an implementation in mind yet though.



    -Hoss


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Chris Hostetter at Sep 3, 2009 at 10:16 pm
    : I wanted to avoid two things:
    : * Writing the logic that invokes cache-refresh upon IndexReader reload.

    Uh... i don't think there is any code that FieldCache refreshing on
    reload (yet), so you wouldn't be missing out on anything. (as long as
    your custom cache works at the SegmentReader level, you'd have the exact
    same benefits as using FieldCache)

    : * Write my own TopFieldCollector which uses this cache.

    well, yeah ... there you're screwed.

    you know ... just because FieldCache.DEFAULT is a static final singleton,
    doesn't mean we need to have FieldCache.DEFAULT hardcoded in so many
    places ... a lot of the high level classes that refer to
    FieldCache.DEFAULT could probably be refacotred to have a
    setFieldCache(FieldCache) method that defaults to FieldCache.DEFAULT, and
    then they could pass it down to the lower level classes ... that way you
    *could* write a "MyFieldCache extends FieldCache", and then have a
    SortComparator (or FieldComparator, or whatever it's called now) that cast
    the FieldCache it gets to your MyFieldCache and calls the custom methods
    ... withoutneeding to rewrite all of hte Collector code.

    It sounds a little invasive to make it into 2.9 ... but i haven't looked
    ito what it would involve ... in theory it could be really straight
    forward and backwards compatible.


    -Hoss


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Shai Erera at Sep 4, 2009 at 4:33 am
    Thanks

    I plan to look into two things, and then probably create two separate
    issues:

    1) Refactor the FieldCache API (and TopFieldCollector) such that one can
    provide its own Cache of native values. I'd hate to rewrite the
    FieldComparators logic just because the current API is not extendable. That
    I agree should be quite straightforward, but I'll need to look into it
    first.

    2) Contribute my payload-based sorting package. Currently it only reads from
    disk during searches, and I'd like to enhance it to use in-memory cache as
    well. It's a moderate-size package, so this one will need to wait until (1)
    is done, and I get enough time to adapt it to 2.9 and work on the issue.

    I definitely don't think this should be a 2.9 sort of work, unless someone
    else volunteers to do it. I can't pull (1) together that quickly.

    I thought that FieldCache is loaded when the IndexReader is reopened no? I
    mean, it's a per IndexReader instance no? If not, then I'll need to rethink
    the entire approach, because then (1) may not be that important anymore.

    Shai
    On Fri, Sep 4, 2009 at 1:15 AM, Chris Hostetter wrote:


    : I wanted to avoid two things:
    : * Writing the logic that invokes cache-refresh upon IndexReader reload.

    Uh... i don't think there is any code that FieldCache refreshing on
    reload (yet), so you wouldn't be missing out on anything. (as long as
    your custom cache works at the SegmentReader level, you'd have the exact
    same benefits as using FieldCache)

    : * Write my own TopFieldCollector which uses this cache.

    well, yeah ... there you're screwed.

    you know ... just because FieldCache.DEFAULT is a static final singleton,
    doesn't mean we need to have FieldCache.DEFAULT hardcoded in so many
    places ... a lot of the high level classes that refer to
    FieldCache.DEFAULT could probably be refacotred to have a
    setFieldCache(FieldCache) method that defaults to FieldCache.DEFAULT, and
    then they could pass it down to the lower level classes ... that way you
    *could* write a "MyFieldCache extends FieldCache", and then have a
    SortComparator (or FieldComparator, or whatever it's called now) that cast
    the FieldCache it gets to your MyFieldCache and calls the custom methods
    ... withoutneeding to rewrite all of hte Collector code.

    It sounds a little invasive to make it into 2.9 ... but i haven't looked
    ito what it would involve ... in theory it could be really straight
    forward and backwards compatible.


    -Hoss


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Michael McCandless at Sep 4, 2009 at 9:18 am

    On Fri, Sep 4, 2009 at 12:33 AM, Shai Ererawrote:

    1) Refactor the FieldCache API (and TopFieldCollector) such that one can
    provide its own Cache of native values. I'd hate to rewrite the
    FieldComparators logic just because the current API is not extendable. That
    I agree should be quite straightforward, but I'll need to look into it
    first.
    +1

    Or, so that the current consumers of FieldCache (that hardwire to
    FieldCache.DEFAULT) could simply accept any other FieldCache
    instance, as Hoss suggested.
    2) Contribute my payload-based sorting package. Currently it only reads from
    disk during searches, and I'd like to enhance it to use in-memory cache as
    well. It's a moderate-size package, so this one will need to wait until (1)
    is done, and I get enough time to adapt it to 2.9 and work on the issue.
    +1, sounds cool!
    I definitely don't think this should be a 2.9 sort of work, unless someone
    else volunteers to do it. I can't pull (1) together that quickly.
    Me too... 2.9 train is moving out of the station now!
    I thought that FieldCache is loaded when the IndexReader is reopened no? I
    mean, it's a per IndexReader instance no? If not, then I'll need to rethink
    the entire approach, because then (1) may not be that important anymore.
    FieldCache is only opened on demand, ie, the first time that a newly
    opened reader calls FieldCache.DEFAULT.getXXX does it get populated.

    So it's not during the reopen... it's during the first query that eg sorts
    by a field.

    It'd be great if your use case gives us enough clarity on LUCENE-831
    to make concrete progress.

    Note that function queries already "wrap" FieldCache w/ an alternate API
    for native value per doc (ValueSource, DocValues, FieldCacheSource),
    that do allow custom ValueSources to be provided. It'd be great if
    as part of LUCENE-831 they could be more unified w/ FieldCache's
    API.

    Mike

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Shai Erera at Sep 4, 2009 at 4:20 pm
    Thanks Mike. I did not phrase well my understanding of Cache reload. I
    didn't mean literally as part of the reopen, but *because* of the reopen.
    Because FieldCache is tied to an IndexReader instance, after reopen it gets
    refreshed. If I keep my own Cache, I'll need to code that logic, and I
    prefer to use what's currently in Lucene. (Sloth? :) )

    I'll look at the mentioned function queries. Thanks for the pointer !

    Shai
    On Fri, Sep 4, 2009 at 12:17 PM, Michael McCandless wrote:

    On Fri, Sep 4, 2009 at 12:33 AM, Shai Ererawrote:
    1) Refactor the FieldCache API (and TopFieldCollector) such that one can
    provide its own Cache of native values. I'd hate to rewrite the
    FieldComparators logic just because the current API is not extendable. That
    I agree should be quite straightforward, but I'll need to look into it
    first.
    +1

    Or, so that the current consumers of FieldCache (that hardwire to
    FieldCache.DEFAULT) could simply accept any other FieldCache
    instance, as Hoss suggested.
    2) Contribute my payload-based sorting package. Currently it only reads from
    disk during searches, and I'd like to enhance it to use in-memory cache as
    well. It's a moderate-size package, so this one will need to wait until (1)
    is done, and I get enough time to adapt it to 2.9 and work on the issue.
    +1, sounds cool!
    I definitely don't think this should be a 2.9 sort of work, unless someone
    else volunteers to do it. I can't pull (1) together that quickly.
    Me too... 2.9 train is moving out of the station now!
    I thought that FieldCache is loaded when the IndexReader is reopened no? I
    mean, it's a per IndexReader instance no? If not, then I'll need to rethink
    the entire approach, because then (1) may not be that important anymore.
    FieldCache is only opened on demand, ie, the first time that a newly
    opened reader calls FieldCache.DEFAULT.getXXX does it get populated.

    So it's not during the reopen... it's during the first query that eg sorts
    by a field.

    It'd be great if your use case gives us enough clarity on LUCENE-831
    to make concrete progress.

    Note that function queries already "wrap" FieldCache w/ an alternate API
    for native value per doc (ValueSource, DocValues, FieldCacheSource),
    that do allow custom ValueSources to be provided. It'd be great if
    as part of LUCENE-831 they could be more unified w/ FieldCache's
    API.

    Mike

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Erick Erickson at Sep 5, 2009 at 12:53 am
    No, not sloth. Making use of the fine work that others have done in
    order to help get your product out the door faster/cheaper <G>....

    As in "There's no virtue in re-inventing the wheel. No matter how
    productive it feels" <GGGG>.

    Best
    Erick
    On Fri, Sep 4, 2009 at 12:19 PM, Shai Erera wrote:

    Thanks Mike. I did not phrase well my understanding of Cache reload. I
    didn't mean literally as part of the reopen, but *because* of the reopen.
    Because FieldCache is tied to an IndexReader instance, after reopen it gets
    refreshed. If I keep my own Cache, I'll need to code that logic, and I
    prefer to use what's currently in Lucene. (Sloth? :) )

    I'll look at the mentioned function queries. Thanks for the pointer !

    Shai
    On Fri, Sep 4, 2009 at 12:17 PM, Michael McCandless <
    lucene@mikemccandless.com> wrote:
    On Fri, Sep 4, 2009 at 12:33 AM, Shai Ererawrote:
    1) Refactor the FieldCache API (and TopFieldCollector) such that one
    can
    provide its own Cache of native values. I'd hate to rewrite the
    FieldComparators logic just because the current API is not extendable. That
    I agree should be quite straightforward, but I'll need to look into it
    first.
    +1

    Or, so that the current consumers of FieldCache (that hardwire to
    FieldCache.DEFAULT) could simply accept any other FieldCache
    instance, as Hoss suggested.
    2) Contribute my payload-based sorting package. Currently it only reads from
    disk during searches, and I'd like to enhance it to use in-memory cache as
    well. It's a moderate-size package, so this one will need to wait until (1)
    is done, and I get enough time to adapt it to 2.9 and work on the
    issue.
    +1, sounds cool!
    I definitely don't think this should be a 2.9 sort of work, unless someone
    else volunteers to do it. I can't pull (1) together that quickly.
    Me too... 2.9 train is moving out of the station now!
    I thought that FieldCache is loaded when the IndexReader is reopened
    no?
    I
    mean, it's a per IndexReader instance no? If not, then I'll need to rethink
    the entire approach, because then (1) may not be that important
    anymore.
    FieldCache is only opened on demand, ie, the first time that a newly
    opened reader calls FieldCache.DEFAULT.getXXX does it get populated.

    So it's not during the reopen... it's during the first query that eg sorts
    by a field.

    It'd be great if your use case gives us enough clarity on LUCENE-831
    to make concrete progress.

    Note that function queries already "wrap" FieldCache w/ an alternate API
    for native value per doc (ValueSource, DocValues, FieldCacheSource),
    that do allow custom ValueSources to be provided. It'd be great if
    as part of LUCENE-831 they could be more unified w/ FieldCache's
    API.

    Mike

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Chris Hostetter at Sep 8, 2009 at 10:37 pm
    : Thanks Mike. I did not phrase well my understanding of Cache reload. I
    : didn't mean literally as part of the reopen, but *because* of the reopen.
    : Because FieldCache is tied to an IndexReader instance, after reopen it gets
    : refreshed. If I keep my own Cache, I'll need to code that logic, and I
    : prefer to use what's currently in Lucene. (Sloth? :) )

    but there is no actually refresh anywhere in Lucene ... the first time
    it's used on a reader, it's cached. when that reader gets garbage
    collected, it's remved from the cache. the only way the reopen/segment
    level sorting changed things is that in a multireader the indexreader refs
    put in the cache are all segment readers ... so if you reopen a
    multireader only the changed segments will need to be added to hte cache
    (the others will still be there)

    but extending FieldCache doesn't really help you get any reuse out of that
    that you couldn't get with your own weakhashmap keyed on indexreaders --
    the sorting code will always give your custom Sort the segment readers.



    -Hoss


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Yonik Seeley at Sep 5, 2009 at 3:45 pm

    On Fri, Sep 4, 2009 at 12:33 AM, Shai Ererawrote:
    2) Contribute my payload-based sorting package. Currently it only reads from
    disk during searches, and I'd like to enhance it to use in-memory cache as
    well. It's a moderate-size package, so this one will need to wait until (1)
    is done, and I get enough time to adapt it to 2.9 and work on the issue.
    I've resisted using payloads for this purpose in Solr because it felt
    like an interim hack until CSF is implemented. It feels like payloads
    are properly used when one actually cares what the term or position
    is. Thoughts? Do we think CSF will make it in 3.1?

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Shai Erera at Sep 6, 2009 at 8:42 am

    I've resisted using payloads for this purpose in Solr because it felt
    like an interim hack until CSF is implemented.
    I don't see it as a hack, but as a proper use of a great feature in Lucene.
    CSF and this are essentially the same. Adding document-level metadata, or
    adding a term which puts stuff in the payload feels the same to me. We'll
    definitely need to perf. test the two and compare. The package I wrote
    "hides" this payload stuff from the app developer. If after CSF is
    introduced is makes sense to move to use it, it should be very simple to
    change the sort-by-payload package to use it, w/o affecting apps too much (I
    think and hope).

    The term just describes the "sort-by" type (e.g. date, title, priority etc.)
    and there is only one position and nobody really cares about it and needs to
    know that.

    Shai
    On Sat, Sep 5, 2009 at 6:45 PM, Yonik Seeley wrote:

    On Fri, Sep 4, 2009 at 12:33 AM, Shai Ererawrote:
    2) Contribute my payload-based sorting package. Currently it only reads from
    disk during searches, and I'd like to enhance it to use in-memory cache as
    well. It's a moderate-size package, so this one will need to wait until (1)
    is done, and I get enough time to adapt it to 2.9 and work on the issue.
    I've resisted using payloads for this purpose in Solr because it felt
    like an interim hack until CSF is implemented. It feels like payloads
    are properly used when one actually cares what the term or position
    is. Thoughts? Do we think CSF will make it in 3.1?

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Yonik Seeley at Sep 8, 2009 at 10:40 pm

    On Sun, Sep 6, 2009 at 4:42 AM, Shai Ererawrote:
    I've resisted using payloads for this purpose in Solr because it felt
    like an interim hack until CSF is implemented.
    I don't see it as a hack, but as a proper use of a great feature in Lucene.
    It's proper use for an application perhaps, but not for core Lucene.
    Applications are pretty much required to work with what's given in
    Lucene... but Lucene developers can make better choices. Hence if at
    all possible, work should be put into implementing CSF rather than
    sorting by payloads.
    CSF and this are essentially the same.
    In which case we wouldn't need CSF?

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Shai Erera at Sep 9, 2009 at 3:46 am
    I didn't say we won't need CSF, but that at least conceptually, CSF and my
    sort-by-payload are the same. If however it turns out that CSF performs
    better, then I'll definitely switch my sort-by-payload package to use it. I
    thought that CSF is going to be implemented using payloads, but perhaps I'm
    wrong.

    Shai
    On Wed, Sep 9, 2009 at 1:39 AM, Yonik Seeley wrote:

    On Sun, Sep 6, 2009 at 4:42 AM, Shai Ererawrote:
    I've resisted using payloads for this purpose in Solr because it felt
    like an interim hack until CSF is implemented.
    I don't see it as a hack, but as a proper use of a great feature in
    Lucene.

    It's proper use for an application perhaps, but not for core Lucene.
    Applications are pretty much required to work with what's given in
    Lucene... but Lucene developers can make better choices. Hence if at
    all possible, work should be put into implementing CSF rather than
    sorting by payloads.
    CSF and this are essentially the same.
    In which case we wouldn't need CSF?

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Jason Rutherglen at Sep 10, 2009 at 5:03 pm
    I think CSF hasn't been implemented because it's only marginally
    useful yet requires fairly significant rewrites of core code
    (i.e. SegmentMerger) so no one's picked it up including myself.
    An interim solution that fulfills the same function (quickly
    loading field cache values) using what works reliably today
    (i.e. payloads) is a good simple forward moving step.

    Shai, feel free to open an issue and post your code. I'd will
    check it out and help where possible.
    On Tue, Sep 8, 2009 at 8:46 PM, Shai Erera wrote:
    I didn't say we won't need CSF, but that at least conceptually, CSF and my
    sort-by-payload are the same. If however it turns out that CSF performs
    better, then I'll definitely switch my sort-by-payload package to use it. I
    thought that CSF is going to be implemented using payloads, but perhaps I'm
    wrong.

    Shai
    On Wed, Sep 9, 2009 at 1:39 AM, Yonik Seeley wrote:

    On Sun, Sep 6, 2009 at 4:42 AM, Shai Ererawrote:
    I've resisted using payloads for this purpose in Solr because it felt
    like an interim hack until CSF is implemented.
    I don't see it as a hack, but as a proper use of a great feature in
    Lucene.

    It's proper use for an application perhaps, but not for core Lucene.
    Applications are pretty much required to work with what's given in
    Lucene... but Lucene developers can make better choices.  Hence if at
    all possible, work should be put into implementing CSF rather than
    sorting by payloads.
    CSF and this are essentially the same.
    In which case we wouldn't need CSF?

    -Yonik
    http://www.lucidimagination.com

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-user @
categorieslucene
postedAug 20, '09 at 11:50a
activeSep 10, '09 at 5:03p
posts14
users6
websitelucene.apache.org

People

Translate

site design / logo © 2022 Grokbase