RestHandler has a number of methods that affect the behaviour of request
processing. If the handler is wrapped (e.g. SecurityRestFilter or
DeprecationRestHandler) then these methods must be delegated to the
underlying handler.
This commit introduces a new abstract base class `FilterRestHandler`
that correctly delegates these methods so that wrappers (subclasses) do
not need to implement the behaviour on a case-by-case basis
Backport of: #98861
Prior to this change NodeReplacementAllocationDecider was unconditionally skipping both replacement source and target nodes when calculation auto-expand replicas. This is fixed by autoexpanding to the replacement node if source node already had shards of the index
Backport of PR #96281 amended for 7.17.x
Closes#89527
Co-authored-by: Ievgen Degtiarenko <ievgen.degtiarenko@elastic.co>
This is a backport of multiple work items related to authentication enhancements for HTTP,
which were originally merged in the 8.8 - 8.9 releases.
Hence, the HTTP (only the netty4-based implementation (default), not the NIO one) authentication
implementation gets a throughput boost (especially for requests failing authn).
Relates to: ES-6188 #92220#95112
The docs for this API say the following:
> If the API fails, you can safely retry it. Only a successful response
> guarantees that the node has been removed from the voting
> configuration and will not be reinstated.
Unfortunately this isn't true today: if the request adds no exclusions
then we do not wait before responding. This commit makes the API wait
until all exclusions are really applied.
Backport of #98386, plus the test changes from #98146 and #98356.
This change avoids unnecessary substring allocations and recursion calls
when more than two consecutive wildcards (`*`) are detected. Instead
skipping and calling a method recursively, we now try to skip all
consecutive `*` chars at once.
* Update certs for PKI tests and re-enable tests (#97766)
The certs for the PKI tests expired and the test was muted.
This commit follows the instructions in the read to update the certs and unmutes the test.
The certs will now expire 20 years from now.
fixes: #97756
* precommit
in 2.17.2 (patch release) log4j has made a refactoring that requires a Configuration to be manually passed into the created PatternLayout
If the Configuration is not passed, the System Variable lookup will not work This results in cluster.name field not being populated in logs
This commit creates a PatternLayout with a DefaultConfiguration (the same was used previous to the refactoring)
backports #97679
* Migrate to data tiers routing configures correct default for mounted indices
(cherry picked from commit eaec9602a9c4a4b092f36fd35f58d1e4b8faca52)
Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
* Add isExplicitDataTier method back as it's used in 7.17
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
The current recursive nested field handling implementation in FieldFetcher
can be O(n^2) in the number of nested mappings, whether or not a nested
field has been requested or not. For indexes with a very large number of
nested fields, this can mean it takes multiple seconds to build a FieldFetcher,
making the fetch phase of queries extremely slow, even if no nested fields
are actually asked for.
This commit reworks the logic so that building nested fetchers is only
O(n log n) in the number of nested mappers; additionally, we only pay this
cost for nested fields that have been requested.
* Port lucene fix github-12352 to Elasticsearch 7.17
* Update docs/changelog/96721.yaml
* Support for Byte and Short as vector tiles value tag (#97619)
Byte and short data types are not supported by the vector tiles specification. If a user tries to add one of those, it
actually gets ignored. This add s support to those values by casting them as integers. In addition it will throw an
exception if the value added is a type it cannot understand so it is not silently ignored.
# Conflicts:
# x-pack/plugin/src/yamlRestTest/resources/rest-api-spec/test/vector-tile/10_basic.yml
Today we document that tasks may not react to cancellations immediately,
but in practice it's surprising to users and kind of a bug if they run
for too long after being cancelled. This commit adds a little extra
detail about the information to collect to troubleshoot such a
situation.
Today the `ResultDeduplicator` may complete a collection of listeners in
contexts different from the ones in which they were submitted. This
commit makes sure that the context is preserved in the listener.
Co-authored-by: David Turner <david.turner@elastic.co>
* Handle failure in TransportUpdateAction#handleUpdateFailureWithRetry (#97290)
Here executor(request.getShardId()) may throw, but we're already handling a failure so we cannot simply let this exception bubble up. This commit adjusts things to catch the exception, using it to fail the listener.
Closes#97286
* Fix
---------
Co-authored-by: Iraklis Psaroudakis <kingherc@gmail.com>
Resolves#85928
The after-key parsing is pretty weird, and there are probably more bugs there. I did not take the opportunity to refactor the whole thing, but we should. This fixes the immediate problem by treating after keys as bytes refs when we don't have a field but think we want a keyword. We were already doing that if the user asked for a missing bucket, this just extends the behavior in the case that we don't.
Long term, the terms Composite source (and probably other Composite sources) should have specializations for unmapped fields. That's the direction we want to take aggs in general.
* Update Guava dependency version to 32.0.1-jre
* Fix dependencies
* Remove direct dependencies on guava ver.31
* Revert "Remove direct dependencies on guava ver.31"
This reverts commit 1e90a271c2.
The number of processors available to the jvm can change over time.
However, most of Elasticsearch assumes this value is constant. Although
we could rework all code relying on the number of processors to
dynamically support updates and poll the jvm, doing so has little value
since the processors changing is an edge case. Instead, this commit
fixes validation of the node.processors setting (our internal number of
processors) to validate based on the max processors available at launch.
closes#97088
If there's any file with the `index-` prefix but not a number after that at the repo root we
must not throw here. If we do, we will end up throwing an unexpected exception that is not
properly handled by `org.elasticsearch.snapshots.SnapshotsService#failAllListenersOnMasterFailOver`,
leading to the repository generation not getting correctly set in the cluster state down the line.
[docs] Clarify that index template settings take precedence over component templates.
Co-authored-by: Toby Sutor <55087308+toby-sutor@users.noreply.github.com>
Co-authored-by: Abdon Pijpelink <abdon.pijpelink@elastic.co>
Co-authored-by: Adam Locke <adam.locke@chronosphere.io>
The method `verifyAutoFollowMonitoring` searches for
`ccr_auto_follow_stats` documents in `monitoring-es-*` indices to see if
one document has the field `number_of_successful_follow_indices` greater
than 0.
If such document is found, it means that x-pack monitoring successfully
indexed documents about CCR stats and that CCR at that time had at least
1 following index successfully running.
But the current `verifyAutoFollowMonitoring` method only check the first
10 docs returned by the search requests. Recent failures of
`AutoFollowIT.testAutoFollowPatterns` on 7.17 branch indicates that more
than 10 docs were found, so I suspect one of them has
`number_of_successful_follow_indices` > 0 but is not returned in the
first 10 top docs.
This pull request changes the method to only count documents with
`number_of_successful_follow_indices` > 0.
Closes#91984
This API can be quite heavy in large clusters, and might spam the
`MANAGEMENT` threadpool queue with work for clients that have long-since
given up. This commit adds some basic cancellability checks to reduce
the problem.
Backport of #96551 to 7.17
