The goal of this method is to know whether the xcontent impl knows how to
differenciate floats from doubles or longs from ints or if it's just guessing.
However, all implementations return true (which is correct for yaml and json,
but cbor and smile should be able to differenciate). I first tried to implement
this method correctly but it raised many issues because eg. most impls write a
long as an integer when it is small enough. So I suggest that we remove this
method and just treat cbor and smile like yaml and json, which is already what
is happening today anyway.
The HighlightBuilder should be able to procude a SeachContextHighlight
object which contains the merged global and field options, also
contains objects that can only be created on the index shard (like
the actual lucene Query object used during highlighting).
This is done by the build() method of the HighlighBuilder. Also
adding tests that make sure the produced SearchContextHighlighter is
similar to the one we would get when parsing the xContent directly
with the current HighlightParseElement.
CancellableThreads should also treat ThreadInterruptedException as InterruptedException
RecoverySource uses the RateLimiter under a cancelable thread. The SimpleRateLimiter used in throws ThreadInterruptedException on interruption. We should treat it as InterruptedException
RecoverySource uses the RateLimiter under a cancelable thread. The SimpleRateLimiter used in throws ThreadInterruptedException on interruption. We should treat it as InterruptedException
Currently almost all our fields accept the `analyzer` and `term_vector` settings
although they only make sense on text fields. This commit forbids those settings
on all fields but `string` and `_all` for indices created on or after version
2.2.0.
We have some tests which have crazy dependencies, like on other plugins.
This change adds a "messy-test" gradle plugin which can be used for qa
projects that these types of tests can run in. What this adds over
regular standalone tests is the plugin properties and metadata on the
classpath, so that the plugins are properly initialized.
throw exception if a copy_to is within a multi field
Copy to within multi field is ignored from 2.0 on, see #10802.
Instead of just ignoring it, we should throw an exception if this
is found in the mapping when a mapping is added. For already
existing indices we should at least log a warning.
We remove the copy_to in any case.
related to #14946
this ensures the codebase URL matches the permission grant (see matching toRealPath in Security.java)
in the case of symlinks or other shenanigans.
this is best effort, if we really want to support symlinks in any way, we need
e.g. qa or vagrant tests that configure a bunch of symlinks for things and ensure that in jenkins.
this should be easier to do with gradle, as we can just create a symlink'd home if we want
Today we only handle correctly if the `ExecutionCancelledException` comes from the
local execution. Yet, this can also come from remove and should be handled identically.
This commit restores the chunk size of 512kb lost in a previous but unreleased
refactoring. At the same time it removes the configurability of:
* `indices.recovery.file_chunk_size` - now fixed to 512kb
* `indices.recovery.translog_ops` - removed without replacement
* `indices.recovery.translog_size` - now fixed to 512kb
* `indices.recovery.compress` - file chunks are not compressed due to lucene's compression but translog operations are.
The compress option is gone entirely and compression is used where it makes sense. On sending files of the index
we don't compress as we rely on the lucene compression for stored fields etc.
Relates to #15161
This commit cherry picks some infrastructure changes from the `feature/seq_no` branch to make merging from master easier.
More explicitly, IndexShard current have prepareIndex and prepareDelete methods that are called both on the primary as the replica, giving it a different origin parameter. Instead, this commits creates two explicit prepare*OnPrimary and prepare*OnReplica methods. This has the extra added value of not expecting the caller to use an Engine enum.
Also, the commit adds some code reuse between TransportIndexAction and TransportDeleteAction and their TransportShardBulkAction counter parts.
Closes#15282
The tribe node creates one local client node for each cluster it
connects to. Refactorings in #13383 broke this so that each local client
node now tries to load the full elasticsearch.yml that the real tribe
node uses.
This change fixes the problem by adding a TribeClientNode which is a
subclass of Node. The Environment the node uses is now passed in (in
place of Settings), and the TribeClientNode simply does not use
InternalSettingsPreparer.prepareEnvironment.
The tests around tribe nodes are not great. The existing tests pass, but
I also manually tested by creating 2 local clusters, and configuring and
starting a tribe node. With this I was able to see in the logs the tribe
node connecting to each cluster.
closes#13383
Robert Muir
Lee Hinman
Adrien Grand
Yannick Welsch
Christoph Büscher
Colin Goodheart-Smithe
Boaz Leskes
Ryan Ernst
Robert Muir
Jim Ferenczi
Paulo Martins
Simon Willnauer
Myll
Britta Weber
Simon Willnauer
Jason Tedor