Upgrade to Lucene 4.10

[rmuir]

No description provided.

[jpountz]

LGTM

[kimchy]

left some comments

[s1monw]

LGTM

[rjernst]

I made the merge policy changes, but I have not added a test. There are no existing tests, but there really should be one for each provider checking that the settings can actually be set, and updated. I'll work on these separately, though, unless someone feels it is important to block the upgrade on adding these tests.

[s1monw]

looks good

[kimchy]

@rjernst what about the NamedAnalyzer? I think it should use the same strategy as the analyzer it wraps, no?

[rmuir]

I am sure I made the NamedAnalyzer commit. I just followed Uwe's approach for PerFieldAnalyzerWrapper: this strategy is in fact not used, except as a fallback in the case you wrap namedanalyzer in yet another wrapper (such as shingles) that isnt a pure delegator.

So its just "safety", but maybe there is a way we could just have an error if we do such a thing instead of increased memory usage? Personally I still would prefer if delegation and wrapping use-cases were totally separate and type-safe, but my head is still recovering from looking at this stuff the last time.

[kimchy]

@rmuir yea, I think that in practice, it doesn't matter in the context of NamedAnalyzer, since its just a wrapper. I just think in practice, its cleaner, since NamedAnalyzer is just a delegate, and thats it, not similar to PerfieldAanalyzerWrapper, because of it, I think its cleaner (in the scope of just the NamedAnalyzer impl) to use the same reuse strategy as the analyzer it wraps.

[rmuir]

Right i think the potential for a bug only happens if:

1. NamedAnalyzer wraps something that is per-field (e.g. a PerFieldAnalyzerWrapper)
2. this NamedAnalyzer is wrapped by something that modifies the chain (e.g. shingles or adds charfilter or whatever)

The confusing thing is the API for this "strategy" its passing, again if elasticsearch isn't doing crazy things (and i think its not), then this strategy is never really used:

 /**
  * Constructor.
  * @param fallbackStrategy is the strategy to use if delegation is not possible
  *  This is to support the common pattern:
  *  {@code new OtherWrapper(thisWrapper.getReuseStrategy())} 
  */
 protected DelegatingAnalyzerWrapper(ReuseStrategy fallbackStrategy) {

I guess my suggestion is whether we should force an error in such a "fallback" case, one evil way is to pass ThrowsExceptionOnEveryOperationReuseStrategy instead. There might be cleaner ways.

[kimchy]

I am up for ThrowsExceptionOnEveryOperationReuseStrategy, I think that if we get into a case where we don't fallback, it smells like a bug in ES

[rmuir]

I think those are the 3 choices we have today (since unfortunately we dont have great type safety):

1. if we screw up, its safe but will chew up threadlocals (slower). thats what branch does.
2. if we screw up, its buggy. thats what passing the wrapped strategy does.
3. if we screw up, we get an error and tests fail.

Personally I am for option 3 as well. I will try to think of a cleaner way.

[rmuir]

What is left to do here?

[kimchy]

LGTM