The current implementations of BytesReference.Helper.bytesEquals and
bytesHashCode materialize a byte[] when passed an instance that returns `false`
in `hasArray()`. They should instead do a byte-by-byte comparison/hashcode
computation without materializing the array.
Close#5517
Elasticsearch is release from release-branches but the modifications
to the documentation must be cherry-picked into the current development
branch. To make this easier this commit splits the commits of the
Version and the documenation into seperate commits.
TransportMasterNodeOperationAction forwards incoming requests to the currently known master node. If that fails due to a connection error, a cluster state listener will be added in order to try again when a new master is elected. After the listener is in place, a check was made to see if the master has change *while* the listener was being added so that change will not be missed. The check was not enough as it may be that the same master was re-elected (for example, a network hick up) and thus test will fail even though the re-ellection event was missed. In these cases, the request would timeout unjustly. This commit changes this test to be more strict and retry if the cluster state version changed during the addition of the listener.
Closes#5499
When updating the min_master_nodes setting via the Cluster Settings API, the change is propagated to all nodes. The current master node also updates the ElectMasterService and validates that is still sees enough master eligible nodes and that it's election is still valid. Other master eligible nodes do not go through this validation (good) but also didn't update the ElectMasterService with the new settings. The result is that if the current master goes away, the next election will not be done with the latest setting.
Note - min_master_node set in the elasticsearch.yml file are processed correctly
Closes#5494
Currently we close the store and therefor the underlying directory
when the engine / shard is closed ie. during relocation etc. We also
just close it while there are still searches going on and/or we are
recovering from it. The recoveries might fail which is ok but searches
etc. will be working like pending fetch phases.
The contract of the Directory doesn't prevent to read from a stream
that was already opened before the Directory was closed but from a
system boundary perspective and from lifecycles that we test it seems
to be the right thing to do to wait until all resources are released.
Additionally it will also help to make sure everything is closed
properly before directories are closed itself.
Note: this commit adds Object#wait & Object@#notify/All to forbidden APIs
Closes#5432
Adrien Grand
javanna
Holger Hoffstätte
Boaz Leskes
Kevin Wang
Martijn van Groningen
Igor Motov
Alexander Reelsen
Simon Willnauer
Shay Banon
Bill Hwang
Robert Muir
Clinton Gormley
Jun Ohtani