Tags: AaronFeng2014/elasticsearch
Tags
Fail shard marked as relocating but missing in-memory index structures ( elastic#24061) When a shard is marked as relocating in the cluster state but the node that is to be expected to have the shard does not have the corresponding in-memory index structures loaded, then the node does not notify the master of this inconsistency. The cluster can end up in this situation for example when using discovery.zen.no_master_block: all, which makes the data nodes unload in-memory index structures when no master is available. As a result, all indexing / search activity to the supposedly relocating shard will fail, requiring manual intervention from an operator to fix the issue by restarting the data node with the relocating shard.
Always restore the ThreadContext for operations delayed due to a block ( elastic#23349) The IndexShardOperationsLock has a mechanism to delay operations if there is currently a block on the lock. These delayed operations are executed when the block is released and are executed by a different thread. When the different thread executes the operations, the ThreadContext is that of the thread that was blocking operations. In order to preserve the ThreadContext, we need to store it and wrap the listener when the operation is delayed.
Update java.asciidoc (elastic#23035) A couple more minor errors
Update Painless Loop Counter to be Higher (elastic#22560) Updated Painless loop counter to be 1000000 statements instead of 10000 for update queries.
PreviousNext