Until a couple of hours ago we expected the position_offset_gap to default
to 0 in 2.0 and 100 in 2.1. We decided it was worth backporting that new
default to 2.0. So now that its backported we need to teach 2.1 that 2.0
also defaults to 100.
Closes#7268
This is much more fiddly than you'd expect it to be because of the way
position_offset_gap is applied in StringFieldMapper. Instead of setting
the default to 100 its simpler to make sure that all the analyzers default
to 100 and that StringFieldMapper doesn't override the default unless the
user specifies something different. Unless the index was created before
2.1, in which case the old default of 0 has to take.
Also postition_offset_gaps less than 0 aren't allowed at all.
New tests test that:
1. the new default doesn't match phrases across values with reasonably low
slop (5)
2. the new default doest match phrases across values with reasonably high
slop (50)
3. you can override the value and phrases work as you'd expect
4. if you leave the value undefined in the mapping and define it on a
custom analyzer the the value from the custom analyzer shines through
Closes#7268
This commit changes the startup behavior of Elasticsearch to throw an
exception if duplicate settings keys are detected in the Elasticsearch
configuration file.
Closes#13079
Currently when an entire type is disabled, our document parser will end
parsing on the first field of the document. This blows up the recently
added check that parsing did not silently skip any tokens (ie whether
there was garbage leftover).
This change fixes the parser to correctly skip the entire document when
the type is disabled.
closes#13017
This commit consolidates the logic in
RoutingTable#allActiveShardsGrouped and
RoutingTable#allAssignedShardsGrouped into a single method that merely
applies a predicate to each ShardRouting.
Closes#13081
The `rewrite` option has been removed from the parser with
commit da5fa6c4 and won't parse anymore, however we still
have a setter for it in the builder that gets rendered out
when used and potentially leads to parsing errors. This PR
removes the setter for the unsupported `rewrite` option.
The `rewrite` option has been removed from the parser with
commit da5fa6c4 and won't parse anymore, however we still
have a setter for it in the builder that gets rendered out
when used and potentially leads to parsing errors. This PR
removes the setter for the unsupported `rewrite` option.
This change makes modules added by plugins come before others, as it was
before #12783. The order of configuration, and thereby binding, happens
in the order modules are received, and without this change, some plugins
can get *insane* guice errors (500mb stack trace).
* makes most classes final and package private
* removes duplicate and confusing multiple entry points
* adds javadocs to some classes like JarHell,Security
* adds a public class BootStrapInfo that exposes any stats
needed by outside code.
When we create a plugin's classloader, we should allow it to register things in
the lucene SPI (registry of Tokenizers, TokenFilters, CharFilters, Codec,
PostingsFormat, DocValuesFormat).
Plugins should be able to do this so they can extend Lucene.
We do check if a directory is present and then open a dir stream on
it. Yet the file can be concurrrently deleted which is OK but we fail
with a hard exception. This change tries to open the dir directly (listing via stream)
and catches NoSuchFileEx | FNFEx.
This commit enforces that at most a single settings file is found. If
multiple settings files are found, a SettingsException will be thrown
Closes#13042
This commit fixes an issue that was causing Elasticsearch to silently
ignore settings files that contain garbage. The underlying issue was
swallowing an SettingsException under the assumption that the only
reason that an exception could be throw was due to the settings file
not existing (in this case the IOException would be the cause of the
swallowed SettingsException). This assumption is mistaken as an
IOException could also be thrown due to an access error or a read
error. Additionally, a SettingsException could be thrown exactly
because garbage was found in the settings file. We should instead
explicitly check that the settings file exists, and bomb on an
exception thrown for any reason.
Closes#13028
Today we are very verbose when rendering exceptions on the rest layer.
Yet, this isn't necessarily very easy to read and way too much infromation most
of the time. This change suppresses the stacktrace rendering by default but instead
adds a `rest.suppressed` logger that logs the suppressed stacktrace or rather the entire
exception on the node that renderes the exception
The log message looks like this:
```
[2015-08-19 16:21:58,427][INFO ][rest.suppressed ] /test/_search/ Params: {index=test}
[test] IndexNotFoundException[no such index]
at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:551)
```
Colin Goodheart-Smithe
Boaz Leskes
Nik Everett
Ryan Ernst
javanna
Jason Tedor
Martijn van Groningen
Christoph Büscher
Simon Willnauer
xuzha
Simon Willnauer
Robert Muir
Robert Muir