Added more debug logging to TransportShardReplicationOperationAction
*Changed* node naming in tests from GUIDs to node# based naming as they are much easier to read
This test will make random allocation decision on a growing and
shrinking cluster leading to a random distribution of the shards.
After a certain amount of iterations the test allows allocation unless
the same shard is already allocated on a node and balances the cluster
to gain optimal balance.
The goal is to throw out suggestions that only meet the cutoff in some
shards. This will happen if your input phrase is only contained in a
few shards. If your shards are unbanced this rechecking can throw out
good suggestions.
Closes#3547.
If a path to the test classes contains spaces Hunspell tests failed due
to URL encoded paths. This happens on CI builds if you give the build
a name containing a space. This is fixed by first converting to a URI
and created a File object from the URI directly.
The fact that Maven and Eclipse share the same build directories can trigger
race conditions when both are trying to build at the same time, eg. if you run
`mvn clean test` while Eclipse is up and running: Eclipse will notice that some
class files are missing and start compiling in parallel with Maven.
In a special case if allocations from the "heaviest" to the "lighter" nodes is not possible
due to some allocation decider restrictions like zone awareness. if one zone has for instance
less nodes than another zone so one zone is horribly overloaded from a balanced perspective but we
can't move to the "lighter" shards since otherwise the zone would go over capacity.
Closes#3580
When recovery of a shard fails on a node, the node sends notification to the master with information about the failure. During the period between the shard failure and the time when notification about the failure reaches the master, any changes in shard allocations can trigger the node with the failed shard to allocate this shard again. This allocation (especially if successful) creates a ripple effect of the shard going through failure/started states in order to match the delayed states processed by master. Under certain condition, a node involved in this process might generate warning messages: "marked shard as started, but shard has not been created, mark shard as failed".
This fix makes sure that nodes keep track of failed shard allocations and will not try to allocate such shards repeatedly while waiting for the failure notification to be processed by master.
Shard relocation caused queries to fail in the fetch phase either with a
`AlreadyClosedException` or a `SearchContextMissingException`.
This was caused by the `SearchService` releasing the `SearchContext`s via the
superfluous call of `releaseContextsForShard()` when the
This commit allows for configuring the sort order of missing values in BytesRef
comparators (used for strings) with the following options:
- _first: missing values will appear in the first positions,
- _last: missing values will appear in the last positions (default),
- <any value>: documents with missing sort value will use the given value when
sorting.
Since the default is _last, sorting by string value will have a different
behavior than in previous versions of elasticsearch which used to insert missing
value in the first positions when sorting in ascending order.
Implementation notes:
- Nested sorting is supported through the implementation of
NestedWrappableComparator,
- BytesRefValComparator was mostly broken since no field data implementation
was using it, it is now tested through NoOrdinalsStringFieldDataTests,
- Specialized BytesRefOrdValComparators have been removed now that the ordinals
rely on packed arrays instead of raw arrays,
- Field data tests hierarchy has been changed so that the numeric tests don't
inherit from the string tests anymore,
- When _first or _last is used, internally the comparators are told to use
null or BytesRefFieldComparatorSource.MAX_TERM to replace missing values
(depending on the sort order),
- BytesRefValComparator just replaces missing values with the provided value
and uses them for comparisons,
- BytesRefOrdValComparator multiplies ordinals by 4 so that it can find
ordinals for the missing value and the bottom value which are directly
comparable with the segment ordinals. For example, if the segment values and
ordinals are (a,1) and (b,2), they will be stored internally as (a,4) and
(b,8) and if the missing value is 'ab', it will be assigned 6 as an ordinal,
since it is between 'a' and 'b'. Then if the bottom value is 'abc', it will
be assigned 7 as an ordinal since if it between 'ab' and 'b'.
Closes#896