Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.4, Trunk
    • Component/s: modules/spellchecker
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Our current suggester impls do prefix matching of the incoming text
      against all compiled suggestions, but in some cases it's useful to
      allow infix matching. E.g, Netflix does infix suggestions in their
      search box.

      I did a straightforward impl, just using a normal Lucene index, and
      using PostingsHighlighter to highlight matching tokens in the
      suggestions.

      I think this likely only works well when your suggestions have a
      strong prior ranking (weight input to build), eg Netflix knows
      the popularity of movies.

      1. infixSuggest.png
        166 kB
        Michael McCandless
      2. LUCENE-4845.patch
        50 kB
        Michael McCandless
      3. LUCENE-4845.patch
        46 kB
        Michael McCandless
      4. LUCENE-4845.patch
        26 kB
        Michael McCandless
      5. LUCENE-4845.patch
        12 kB
        Robert Muir
      6. LUCENE-4845.patch
        25 kB
        Michael McCandless
      7. LUCENE-4845.patch
        17 kB
        Michael McCandless

        Activity

        Hide
        Michael McCandless added a comment -

        Initial patch, lots of nocommits, only a basic test so far...

        Show
        Michael McCandless added a comment - Initial patch, lots of nocommits, only a basic test so far...
        Hide
        Michael McCandless added a comment -

        Screen shot showing suggestions for "hear".

        Show
        Michael McCandless added a comment - Screen shot showing suggestions for "hear".
        Hide
        Michael McCandless added a comment -

        This is an example of the infix suggestions:

        Show
        Michael McCandless added a comment - This is an example of the infix suggestions:
        Hide
        Robert Muir added a comment -

        Wouldnt the straightforward impl be to put the suffixes of the suggestions into the FST?

        so for "this is a test"
        you also add "is a test", "a test", ...

        I feel like this could be done with just a tokenfilter used only at build-time + analyzingsuggester, and would be more performant.

        Show
        Robert Muir added a comment - Wouldnt the straightforward impl be to put the suffixes of the suggestions into the FST? so for "this is a test" you also add "is a test", "a test", ... I feel like this could be done with just a tokenfilter used only at build-time + analyzingsuggester, and would be more performant.
        Hide
        Michael McCandless added a comment -

        Another iteration:

        • I use SortingAtomicReader to sort all docs by weight (impact
          sorted postings), and then during the search I stop after
          collecting the first N docs.
        • I index leading ngrams up to a limit (default 4 characters) and
          use those instead of PrefixQuery when the last term is short.
        • I switched to a custom highlighter so prefix matches will always
          highlight correctly.

        I tested on the FreeDB corpus (song titles) ... this is a pretty big
        set of suggestions: 44.5 M songs across 3.2 M albums. I pick a random
        subset of the titles, and then test 2,4,6,8 length prefixes:

        • 852 sec to build
        • 3.7 GB index
        • Prefix 2: 50656.1 lookups/sec
        • Prefix 4: 1361.0 lookups/sec
        • Prefix 6: 7291.0 lookups/sec
        • Prefix 8: 5364.5 lookups/sec
        • Prefix 10: 4144.0 lookups/sec

        Eg AnalyzingSuggester (which doesn't highlight so it's not quite a
        fair comparison):

        • 641 sec to build
        • 2.1 GB FST
        • Prefix 2: 9719.3 lookups/sec
        • Prefix 4: 15750.2 lookups/sec
        • Prefix 6: 21491.4 lookups/sec
        • Prefix 8: 27453.4 lookups/sec
        • Prefix 10: 33168.4 lookups/sec

        So it's quite a bit slower than AnalyzingSuggester but I think it's
        still plenty fast for most apps (this is perf for a single thread).

        Show
        Michael McCandless added a comment - Another iteration: I use SortingAtomicReader to sort all docs by weight (impact sorted postings), and then during the search I stop after collecting the first N docs. I index leading ngrams up to a limit (default 4 characters) and use those instead of PrefixQuery when the last term is short. I switched to a custom highlighter so prefix matches will always highlight correctly. I tested on the FreeDB corpus (song titles) ... this is a pretty big set of suggestions: 44.5 M songs across 3.2 M albums. I pick a random subset of the titles, and then test 2,4,6,8 length prefixes: 852 sec to build 3.7 GB index Prefix 2: 50656.1 lookups/sec Prefix 4: 1361.0 lookups/sec Prefix 6: 7291.0 lookups/sec Prefix 8: 5364.5 lookups/sec Prefix 10: 4144.0 lookups/sec Eg AnalyzingSuggester (which doesn't highlight so it's not quite a fair comparison): 641 sec to build 2.1 GB FST Prefix 2: 9719.3 lookups/sec Prefix 4: 15750.2 lookups/sec Prefix 6: 21491.4 lookups/sec Prefix 8: 27453.4 lookups/sec Prefix 10: 33168.4 lookups/sec So it's quite a bit slower than AnalyzingSuggester but I think it's still plenty fast for most apps (this is perf for a single thread).
        Hide
        Michael McCandless added a comment -

        Wouldnt the straightforward impl be to put the suffixes of the suggestions into the FST?

        I think so ... but then I worry about the FST blowing up. I guess if we limit how "deep" the infixing can work that would limit the FST size ... but I'd rather not have that limit.

        We should definitely try it ... it should be a lot faster. I wonder how we could get highlighting working with AnalyzingSuggester.

        Show
        Michael McCandless added a comment - Wouldnt the straightforward impl be to put the suffixes of the suggestions into the FST? I think so ... but then I worry about the FST blowing up. I guess if we limit how "deep" the infixing can work that would limit the FST size ... but I'd rather not have that limit. We should definitely try it ... it should be a lot faster. I wonder how we could get highlighting working with AnalyzingSuggester.
        Hide
        Robert Muir added a comment -

        I think so ... but then I worry about the FST blowing up. I guess if we limit how "deep" the infixing can work that would limit the FST size ... but I'd rather not have that limit.

        But how is this any different than edge-ngrams up to a limit?

        With words of <= 4 chars, this suggester avoids the typical bad complexity you would get from an inverted index because the docids are pre-sorted in weight-order, so it can early terminate.

        But as soon as you type that 5th character: it can blow up. I'm not saying its likely, but can happen due to particulars of the content, for example if you had place names and you typed Shangh... and this prefix matches millions and millions of terms.

        Show
        Robert Muir added a comment - I think so ... but then I worry about the FST blowing up. I guess if we limit how "deep" the infixing can work that would limit the FST size ... but I'd rather not have that limit. But how is this any different than edge-ngrams up to a limit? With words of <= 4 chars, this suggester avoids the typical bad complexity you would get from an inverted index because the docids are pre-sorted in weight-order, so it can early terminate. But as soon as you type that 5th character: it can blow up. I'm not saying its likely, but can happen due to particulars of the content, for example if you had place names and you typed Shangh... and this prefix matches millions and millions of terms.
        Hide
        Robert Muir added a comment -

        ok here's the start of a hack patch. my trivial test passes.

        the whole thing is a nocommit (and there is no depth bound for the infixing).

        Its also probably really slow and buggy

        Show
        Robert Muir added a comment - ok here's the start of a hack patch. my trivial test passes. the whole thing is a nocommit (and there is no depth bound for the infixing). Its also probably really slow and buggy
        Hide
        Robert Muir added a comment -

        And this one is FuzzyAnalyzingInfixSuggester so you have to top that with your perf tests

        Show
        Robert Muir added a comment - And this one is FuzzyAnalyzingInfixSuggester so you have to top that with your perf tests
        Hide
        Robert Muir added a comment -

        This seems to not blow up for title-like fields:
        I did a quick test of geonames (8.3M place names, just using ID as the weight)

        AnalyzingSuggester: 117444563 bytes, 74887ms build time
        InfixingSuggester: 302127665 bytes, 125895ms build time
        

        I think realistically an N limit can work well here. After such a limit, the infixing is
        pretty crazy anyway, and really infixing should "punish" the weight in some way since its
        a very scary "edit" operation to do to the user.

        Plus you get optional fuzziness and real "phrasing" works too

        Show
        Robert Muir added a comment - This seems to not blow up for title-like fields: I did a quick test of geonames (8.3M place names, just using ID as the weight) AnalyzingSuggester: 117444563 bytes, 74887ms build time InfixingSuggester: 302127665 bytes, 125895ms build time I think realistically an N limit can work well here. After such a limit, the infixing is pretty crazy anyway, and really infixing should "punish" the weight in some way since its a very scary "edit" operation to do to the user. Plus you get optional fuzziness and real "phrasing" works too
        Hide
        Michael McCandless added a comment -

        I like this approach! (Add epsilon transitions after the automaton is built).

        I managed to build the FreeDB suggest using this but ... it required a lot of RAM: it OOM'd at 14 GB heap but finished successfully at 20 GB heap.

        Took a longish time to build too, and made a biggish FST (more than 2X larger than the index):

        • 2466 sec to build
        • FST is 8.6 GB
        • Prefix 2: 2527.5 lookups/sec
        • Prefix 4: 1681.7 lookups/sec
        • Prefix 6: 1948.3 lookups/sec
        • Prefix 8: 2050.9 lookups/sec
        • Prefix 10: 2076.0 lookups/sec

        We should try the N prefix limit ... but I don't really like that. Maybe we should just offer both approaches ...

        Show
        Michael McCandless added a comment - I like this approach! (Add epsilon transitions after the automaton is built). I managed to build the FreeDB suggest using this but ... it required a lot of RAM: it OOM'd at 14 GB heap but finished successfully at 20 GB heap. Took a longish time to build too, and made a biggish FST (more than 2X larger than the index): 2466 sec to build FST is 8.6 GB Prefix 2: 2527.5 lookups/sec Prefix 4: 1681.7 lookups/sec Prefix 6: 1948.3 lookups/sec Prefix 8: 2050.9 lookups/sec Prefix 10: 2076.0 lookups/sec We should try the N prefix limit ... but I don't really like that. Maybe we should just offer both approaches ...
        Hide
        Robert Muir added a comment -

        I managed to build the FreeDB suggest using this but ... it required a lot of RAM: it OOM'd at 14 GB heap but finished successfully at 20 GB heap.

        Took a longish time to build too, and made a biggish FST (more than 2X larger than the index):

        I think its because your FreeDB has a lot more words than my place names?

        But really there must be a infixing limit for relevance reasons alone.

        We should try the N prefix limit ... but I don't really like that. Maybe we should just offer both approaches ...

        Why is it so bad, but the edge-ngrams limit ok?

        Show
        Robert Muir added a comment - I managed to build the FreeDB suggest using this but ... it required a lot of RAM: it OOM'd at 14 GB heap but finished successfully at 20 GB heap. Took a longish time to build too, and made a biggish FST (more than 2X larger than the index): I think its because your FreeDB has a lot more words than my place names? But really there must be a infixing limit for relevance reasons alone. We should try the N prefix limit ... but I don't really like that. Maybe we should just offer both approaches ... Why is it so bad, but the edge-ngrams limit ok?
        Hide
        Michael McCandless added a comment -

        I think its because your FreeDB has a lot more words than my place names?

        I think so. Song titles are longer than place names

        But really there must be a infixing limit for relevance reasons alone.

        I think the app can decide this.

        Why is it so bad, but the edge-ngrams limit ok?

        I don't think either limit is OK! In the ideal world we wouldn't require such limits due to performance/RAM issues.

        But no suggester is perfect, this is why we offer multiple options. These two approaches have different tradeoffs...

        Show
        Michael McCandless added a comment - I think its because your FreeDB has a lot more words than my place names? I think so. Song titles are longer than place names But really there must be a infixing limit for relevance reasons alone. I think the app can decide this. Why is it so bad, but the edge-ngrams limit ok? I don't think either limit is OK! In the ideal world we wouldn't require such limits due to performance/RAM issues. But no suggester is perfect, this is why we offer multiple options. These two approaches have different tradeoffs...
        Hide
        Robert Muir added a comment -

        I don't think either limit is OK! In the ideal world we wouldn't require such limits due to performance/RAM issues.

        You still misunderstand me. I dont want the limit for performance/RAM reasons. I want it for relevance reasons. It
        just also gives better performance and memory for free. this is a really simple thing to do mike. Its a win/win

        On the other hand your edge-ngrams limit is completely different. When exceeded, it causes that suggester to work
        in linear time!

        Show
        Robert Muir added a comment - I don't think either limit is OK! In the ideal world we wouldn't require such limits due to performance/RAM issues. You still misunderstand me. I dont want the limit for performance/RAM reasons. I want it for relevance reasons. It just also gives better performance and memory for free. this is a really simple thing to do mike. Its a win/win On the other hand your edge-ngrams limit is completely different. When exceeded, it causes that suggester to work in linear time!
        Hide
        Michael McCandless added a comment -

        Just checkpointing my current patch, with changes from http://jirasearch.mikemccandless.com ... still lots of nocommits ...

        Show
        Michael McCandless added a comment - Just checkpointing my current patch, with changes from http://jirasearch.mikemccandless.com ... still lots of nocommits ...
        Hide
        Shai Erera added a comment -

        Oops, I hit something on the keyboard while reading the issue and it just assigned it to me .

        Show
        Shai Erera added a comment - Oops, I hit something on the keyboard while reading the issue and it just assigned it to me .
        Hide
        Michael McCandless added a comment -

        New patch, fixing nocommits, adding tests.

        Show
        Michael McCandless added a comment - New patch, fixing nocommits, adding tests.
        Hide
        Michael McCandless added a comment -

        New patch, adding the boolean allTermsRequired to the protected
        finishTerms method, and fixed the ForkLastToken test case to only join
        the last two tokens when the term is the same.

        I also pushed the latest patch to the Jira search
        (http://jirasearch.mikemccandless.com), which uses
        AnalyzingInfixSuggester for the auto-suggest, and it seems to be
        working.

        Here's the benchmark results:

         -- construction time
         FuzzySuggester  input: 50001, time[ms]: 266 [+- 9.15]
         AnalyzingSuggester input: 50001, time[ms]: 270 [+- 41.81]
         AnalyzingInfixSuggester input: 50001, time[ms]: 360 [+- 7.14]
         JaspellLookup   input: 50001, time[ms]: 22 [+- 4.23]
         TSTLookup       input: 50001, time[ms]: 75 [+- 1.48]
         FSTCompletionLookup input: 50001, time[ms]: 127 [+- 3.34]
         WFSTCompletionLookup input: 50001, time[ms]: 119 [+- 3.84]
        
         -- prefixes: 2-4, num: 7, onlyMorePopular: false
         FuzzySuggester  queries: 50001, time[ms]: 2130 [+- 12.05], ~kQPS: 23
         AnalyzingSuggester queries: 50001, time[ms]: 642 [+- 8.80], ~kQPS: 78
         AnalyzingInfixSuggester queries: 50001, time[ms]: 863 [+- 9.50], ~kQPS: 58
         JaspellLookup   queries: 50001, time[ms]: 131 [+- 3.91], ~kQPS: 381
         TSTLookup       queries: 50001, time[ms]: 467 [+- 0.96], ~kQPS: 107
         FSTCompletionLookup queries: 50001, time[ms]: 369 [+- 5.21], ~kQPS: 135
         WFSTCompletionLookup queries: 50001, time[ms]: 291 [+- 4.64], ~kQPS: 172
        
         -- prefixes: 6-9, num: 7, onlyMorePopular: false
         FuzzySuggester  queries: 50001, time[ms]: 3216 [+- 14.12], ~kQPS: 16
         AnalyzingSuggester queries: 50001, time[ms]: 275 [+- 4.10], ~kQPS: 182
         AnalyzingInfixSuggester queries: 50001, time[ms]: 656 [+- 10.20], ~kQPS: 76
         JaspellLookup   queries: 50001, time[ms]: 73 [+- 3.17], ~kQPS: 688
         TSTLookup       queries: 50001, time[ms]: 61 [+- 1.99], ~kQPS: 815
         FSTCompletionLookup queries: 50001, time[ms]: 273 [+- 2.45], ~kQPS: 183
         WFSTCompletionLookup queries: 50001, time[ms]: 86 [+- 3.49], ~kQPS: 579
        
         -- prefixes: 100-200, num: 7, onlyMorePopular: false
         FuzzySuggester  queries: 50001, time[ms]: 3572 [+- 14.58], ~kQPS: 14
         AnalyzingSuggester queries: 50001, time[ms]: 251 [+- 4.99], ~kQPS: 199
         AnalyzingInfixSuggester queries: 50001, time[ms]: 502 [+- 12.07], ~kQPS: 100
         JaspellLookup   queries: 50001, time[ms]: 57 [+- 3.38], ~kQPS: 873
         TSTLookup       queries: 50001, time[ms]: 27 [+- 1.74], ~kQPS: 1851
         FSTCompletionLookup queries: 50001, time[ms]: 254 [+- 1.47], ~kQPS: 197
         WFSTCompletionLookup queries: 50001, time[ms]: 62 [+- 3.34], ~kQPS: 807
        
         -- RAM consumption
         FuzzySuggester  size[B]:      765,461
         AnalyzingSuggester size[B]:      765,461
         AnalyzingInfixSuggester size[B]:    2,228,216
         JaspellLookup   size[B]:    9,815,144
         TSTLookup       size[B]:    9,459,256
         FSTCompletionLookup size[B]:      376,896
         WFSTCompletionLookup size[B]:      450,384
        
        Show
        Michael McCandless added a comment - New patch, adding the boolean allTermsRequired to the protected finishTerms method, and fixed the ForkLastToken test case to only join the last two tokens when the term is the same. I also pushed the latest patch to the Jira search ( http://jirasearch.mikemccandless.com ), which uses AnalyzingInfixSuggester for the auto-suggest, and it seems to be working. Here's the benchmark results: -- construction time FuzzySuggester input: 50001, time[ms]: 266 [+- 9.15] AnalyzingSuggester input: 50001, time[ms]: 270 [+- 41.81] AnalyzingInfixSuggester input: 50001, time[ms]: 360 [+- 7.14] JaspellLookup input: 50001, time[ms]: 22 [+- 4.23] TSTLookup input: 50001, time[ms]: 75 [+- 1.48] FSTCompletionLookup input: 50001, time[ms]: 127 [+- 3.34] WFSTCompletionLookup input: 50001, time[ms]: 119 [+- 3.84] -- prefixes: 2-4, num: 7, onlyMorePopular: false FuzzySuggester queries: 50001, time[ms]: 2130 [+- 12.05], ~kQPS: 23 AnalyzingSuggester queries: 50001, time[ms]: 642 [+- 8.80], ~kQPS: 78 AnalyzingInfixSuggester queries: 50001, time[ms]: 863 [+- 9.50], ~kQPS: 58 JaspellLookup queries: 50001, time[ms]: 131 [+- 3.91], ~kQPS: 381 TSTLookup queries: 50001, time[ms]: 467 [+- 0.96], ~kQPS: 107 FSTCompletionLookup queries: 50001, time[ms]: 369 [+- 5.21], ~kQPS: 135 WFSTCompletionLookup queries: 50001, time[ms]: 291 [+- 4.64], ~kQPS: 172 -- prefixes: 6-9, num: 7, onlyMorePopular: false FuzzySuggester queries: 50001, time[ms]: 3216 [+- 14.12], ~kQPS: 16 AnalyzingSuggester queries: 50001, time[ms]: 275 [+- 4.10], ~kQPS: 182 AnalyzingInfixSuggester queries: 50001, time[ms]: 656 [+- 10.20], ~kQPS: 76 JaspellLookup queries: 50001, time[ms]: 73 [+- 3.17], ~kQPS: 688 TSTLookup queries: 50001, time[ms]: 61 [+- 1.99], ~kQPS: 815 FSTCompletionLookup queries: 50001, time[ms]: 273 [+- 2.45], ~kQPS: 183 WFSTCompletionLookup queries: 50001, time[ms]: 86 [+- 3.49], ~kQPS: 579 -- prefixes: 100-200, num: 7, onlyMorePopular: false FuzzySuggester queries: 50001, time[ms]: 3572 [+- 14.58], ~kQPS: 14 AnalyzingSuggester queries: 50001, time[ms]: 251 [+- 4.99], ~kQPS: 199 AnalyzingInfixSuggester queries: 50001, time[ms]: 502 [+- 12.07], ~kQPS: 100 JaspellLookup queries: 50001, time[ms]: 57 [+- 3.38], ~kQPS: 873 TSTLookup queries: 50001, time[ms]: 27 [+- 1.74], ~kQPS: 1851 FSTCompletionLookup queries: 50001, time[ms]: 254 [+- 1.47], ~kQPS: 197 WFSTCompletionLookup queries: 50001, time[ms]: 62 [+- 3.34], ~kQPS: 807 -- RAM consumption FuzzySuggester size[B]: 765,461 AnalyzingSuggester size[B]: 765,461 AnalyzingInfixSuggester size[B]: 2,228,216 JaspellLookup size[B]: 9,815,144 TSTLookup size[B]: 9,459,256 FSTCompletionLookup size[B]: 376,896 WFSTCompletionLookup size[B]: 450,384
        Hide
        Michael McCandless added a comment -

        I think the last patch is ready ... I'll commit this soon if there are no objections!

        Show
        Michael McCandless added a comment - I think the last patch is ready ... I'll commit this soon if there are no objections!
        Hide
        Artem Lukanin added a comment -

        I guess, there should be an AnalyzingInfixLookupFactory in Solr as well?

        Show
        Artem Lukanin added a comment - I guess, there should be an AnalyzingInfixLookupFactory in Solr as well?
        Hide
        Michael McCandless added a comment -

        I guess, there should be an AnalyzingInfixLookupFactory in Solr as well?

        I agree ... but this can be done separately.

        Show
        Michael McCandless added a comment - I guess, there should be an AnalyzingInfixLookupFactory in Solr as well? I agree ... but this can be done separately.
        Hide
        Shai Erera added a comment -

        Mike, will you still commit it to 4.4? I think that the branch was created prematurely as there's still no resolution on whether to release or not. And this feature is pretty isolated to cause any instability ... it'd be a petty to have to wait with releasing it another 3-4 months just because of technicalities...

        Show
        Shai Erera added a comment - Mike, will you still commit it to 4.4? I think that the branch was created prematurely as there's still no resolution on whether to release or not. And this feature is pretty isolated to cause any instability ... it'd be a petty to have to wait with releasing it another 3-4 months just because of technicalities...
        Hide
        Michael McCandless added a comment -

        Mike, will you still commit it to 4.4?

        OK I'll commit shortly & backport to 4.4 branch...

        Show
        Michael McCandless added a comment - Mike, will you still commit it to 4.4? OK I'll commit shortly & backport to 4.4 branch...
        Hide
        ASF subversion and git services added a comment -

        Commit 1503340 from Michael McCandless in branch 'dev/trunk'
        [ https://svn.apache.org/r1503340 ]

        LUCENE-4845: add AnalyzingInfixSuggester

        Show
        ASF subversion and git services added a comment - Commit 1503340 from Michael McCandless in branch 'dev/trunk' [ https://svn.apache.org/r1503340 ] LUCENE-4845 : add AnalyzingInfixSuggester
        Hide
        ASF subversion and git services added a comment -

        Commit 1503356 from Michael McCandless in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1503356 ]

        LUCENE-4845: add AnalyzingInfixSuggester

        Show
        ASF subversion and git services added a comment - Commit 1503356 from Michael McCandless in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1503356 ] LUCENE-4845 : add AnalyzingInfixSuggester
        Hide
        ASF subversion and git services added a comment -

        Commit 1503359 from Michael McCandless in branch 'dev/branches/lucene_solr_4_4'
        [ https://svn.apache.org/r1503359 ]

        LUCENE-4845: add AnalyzingInfixSuggester

        Show
        ASF subversion and git services added a comment - Commit 1503359 from Michael McCandless in branch 'dev/branches/lucene_solr_4_4' [ https://svn.apache.org/r1503359 ] LUCENE-4845 : add AnalyzingInfixSuggester
        Hide
        ASF subversion and git services added a comment -

        Commit 1503458 from Michael McCandless in branch 'dev/trunk'
        [ https://svn.apache.org/r1503458 ]

        LUCENE-4845: close tmp directory; fix test to catch un-closed files; add missing suggester.close()

        Show
        ASF subversion and git services added a comment - Commit 1503458 from Michael McCandless in branch 'dev/trunk' [ https://svn.apache.org/r1503458 ] LUCENE-4845 : close tmp directory; fix test to catch un-closed files; add missing suggester.close()
        Hide
        ASF subversion and git services added a comment -

        Commit 1503459 from Michael McCandless in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1503459 ]

        LUCENE-4845: close tmp directory; fix test to catch un-closed files; add missing suggester.close()

        Show
        ASF subversion and git services added a comment - Commit 1503459 from Michael McCandless in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1503459 ] LUCENE-4845 : close tmp directory; fix test to catch un-closed files; add missing suggester.close()
        Hide
        ASF subversion and git services added a comment -

        Commit 1503460 from Michael McCandless in branch 'dev/branches/lucene_solr_4_4'
        [ https://svn.apache.org/r1503460 ]

        LUCENE-4845: close tmp directory; fix test to catch un-closed files; add missing suggester.close()

        Show
        ASF subversion and git services added a comment - Commit 1503460 from Michael McCandless in branch 'dev/branches/lucene_solr_4_4' [ https://svn.apache.org/r1503460 ] LUCENE-4845 : close tmp directory; fix test to catch un-closed files; add missing suggester.close()
        Hide
        ASF subversion and git services added a comment -

        Commit 1503476 from Steve Rowe in branch 'dev/trunk'
        [ https://svn.apache.org/r1503476 ]

        LUCENE-4845: Maven and IntelliJ config

        Show
        ASF subversion and git services added a comment - Commit 1503476 from Steve Rowe in branch 'dev/trunk' [ https://svn.apache.org/r1503476 ] LUCENE-4845 : Maven and IntelliJ config
        Hide
        ASF subversion and git services added a comment -

        Commit 1503477 from Steve Rowe in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1503477 ]

        LUCENE-4845: Maven and IntelliJ config (merged trunk r1503476)

        Show
        ASF subversion and git services added a comment - Commit 1503477 from Steve Rowe in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1503477 ] LUCENE-4845 : Maven and IntelliJ config (merged trunk r1503476)
        Hide
        ASF subversion and git services added a comment -

        Commit 1503478 from Steve Rowe in branch 'dev/branches/lucene_solr_4_4'
        [ https://svn.apache.org/r1503478 ]

        LUCENE-4845: Maven and IntelliJ config (merged trunk r1503476)

        Show
        ASF subversion and git services added a comment - Commit 1503478 from Steve Rowe in branch 'dev/branches/lucene_solr_4_4' [ https://svn.apache.org/r1503478 ] LUCENE-4845 : Maven and IntelliJ config (merged trunk r1503476)
        Hide
        Steve Rowe added a comment -

        Bulk close resolved 4.4 issues

        Show
        Steve Rowe added a comment - Bulk close resolved 4.4 issues

          People

          • Assignee:
            Michael McCandless
            Reporter:
            Michael McCandless
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development