Do not execute bind on on the LDAP reader thread
Each LDAP connection has a single associated thread, executing the handlers for async requests; this is managed by the LDAP library. The bind operation is blocking for the connection. It is a deadlock to call bind, if on the LDAP reader thread for the same connection, because waiting for the bind response blocks the thread processing responses (for this connection).
This will execute the bind operation (and the subsequent runnable) on a thread pool after checking for the conflict above.
Closes: elastic/x-pack-elasticsearch#2570, elastic/x-pack-elasticsearch#2620
Original commit: elastic/x-pack-elasticsearch@404a3d8737
Uses the appropriate overload of `generateRandomStringArray` to disallow empty arrays from being returned.
Original commit: elastic/x-pack-elasticsearch@2596653ca1
Since the transport ssl enabled setting is usable in 6.x again, this change adds back the value to
the xpack security usage so that it can be included in phone home data.
Original commit: elastic/x-pack-elasticsearch@52f6176df0
The upgrade API adds a "type" field to role mapping documents.
The parser would reject these docs due to an unexpected field. We now ignore the "type" field instead.
Original commit: elastic/x-pack-elasticsearch@538f5adab2
Those classes used to be elasticsearch-agnostic wrappers
of the query parameters. However, we now do not need that
layer of abstraction. Instead we can make those builders
own the building of the SearchSourceBuilder, which
simplifies the JobProvider and makes them reusable.
Original commit: elastic/x-pack-elasticsearch@b079cce1d6
Since we are authorising on a single shard of a single index,
and there are only 3 possible actions that an item might represent,
we can test which items are authorised with a maximum of 3 permission
evaluations, regardless of how many items are actually in the shard
request. Previously we would test them all independently which had
a much higher overhead for large bulk requests.
Relates: elastic/x-pack-elasticsearch#2369
Original commit: elastic/x-pack-elasticsearch@aceacf0aa3
A number of REST requests require a body but did not explicitly validate for it.
This would typically cause a NPE if they were called with no body.
Original commit: elastic/x-pack-elasticsearch@863ac89429
The test also used the timewarp trigger for watches to be executed, but it is sufficient to just call the execute watch API to make this test faster.
Original commit: elastic/x-pack-elasticsearch@3a4165f72c
When getting a single bucket, the get_buckets API can take a timestamp
either in the body or in the URL. Prior to this change, if a timestamp
was specified in the URL but a body not containing a timestamp was specified
(either empty or containing other parameters like exclude_interim or sort)
then it would cause a bad_request exception. This in turn causes problems
for clients that cannot send a body when GETting and always send a body when
POSTing.
This change fixes get_buckets to always read any timestamp in the URL, even
when a body is sent.
relates elastic/x-pack-elasticsearch#2515
Original commit: elastic/x-pack-elasticsearch@5c23dd972e
If a job close is requested after a job was opened but before
its process was launched, the job close returns successfully
without doing anything. The result is that the process hangs
around. This has been causing test failures as documented
int elastic/x-pack-elasticsearch#2360 and elastic/x-pack-elasticsearch#1270.
This commit fixes this problem by refactoring the
AutodetectProcessManager. It introduces a state pattern
to make clear the states of the process and it uses locking
to ensure a close waits for the job process to be created.
relates elastic/x-pack-elasticsearch#1270
Original commit: elastic/x-pack-elasticsearch@ff858bd136
The AuthenticationService#testInvalidToken would cause a suite timeout in the case of an exception
due to a incorrect stream size as the latch was never counted down. This fixes the missing latch
countdown.
relates elastic/x-pack-elasticsearch#2615
Original commit: elastic/x-pack-elasticsearch@e838e6e912
* Switch `ResultSet#getFetchSize` from returning the *requested*
fetch size to returning the size of the current page of results.
For scrolling searches without parent/child this'll match the
requested fetch size but for other things it won't. The nice thing
about this is that it lets us tell users a thing to look at if
they are wondering why they are using a bunch of memory.
* Remove all the entire JDBC action and implement it on the REST
layer instead.
* Create some code that can be shared between the cli and jdbc
actions to properly handle errors and request deserialization so
there isn't as much copy and paste between the two. This helps
because it calls out explicitly the places where they are different.
* I have not moved the CLI REST handle to shared code because
I think it'd be clearer to make that change in a followup PR.
* There is now no more need for constructs that allow iterating
all of the results in the same request. I have not removed these
because I feel that that cleanup is big enough to deserve its own
PR.
Original commit: elastic/x-pack-elasticsearch@3b12afd11c
Checking the size of the map doesn't make sense when each filter is
checked independently right after.
Original commit: elastic/x-pack-elasticsearch@58e5d3401d
This is related to elastic/x-pack-elasticsearch#1941.
Currently we support self-generating either a basic or trial license at
cluster startup. With the addition of the basic option, it is possible
that a user would choose to self-generate and eventually register a
basic license.
This commit allows a user to upgrade to a 30-day trial license if they
have not already utilized this 30-day trial license before. Additionally
it adds a get route to check if the user is eligible to upgrade. This
route will allow kibana to implement a cleaner UI.
Original commit: elastic/x-pack-elasticsearch@7f19b33a08
This removes the creation and handling of the Beats monitoring template and its data until we actually expect to support it (most likely 6.2 - 6.3).
Original commit: elastic/x-pack-elasticsearch@2dc8abbb37
Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into
qa modules with different running server configurations. The
big advantage of this is that it allows us to test the cli and
jdbc with security present.
Creating a project that depends on both cli and jdbc and the
server has some prickly jar hell issues because cli and jdbc
package their dependencies in the jar. This works around it
in a few days:
1. Include only a single copy of the JDBC dependencies with
careful gradle work.
2. Do not include the CLI on the classpath at all and instead
run it externally.
I say "run it externally" rather than "fork it" because Elasticsearch
tests aren't allowed to fork other processes. This is forbidden
by seccomp on linux and seatbelt on osx and cannot be explicitly
requested like additional security manager settings. So instead
of forking the CLI process directly the tests interact with a test
fixture that isn't bound by Elasticsearch's rules and *can* fork
it.
This forking of the CLI has a nice side effect: it forces us to
make sure that things like security and connection strings other
than `localhost:9200` work. The old test could and did work around
missing features like that. The new tests cannot so I added the
ability to set the connection string. Configuring usernames and
passwords was also not supported but I did not add support for
that, only created the failing test and marked it as `@AwaitsFix`.
Original commit: elastic/x-pack-elasticsearch@560c6815e3
Igor Motov
Albert Zaharovits
Simon Willnauer
Nik Everett
Chris Earle
David Roberts
Jay Modi
Tim Vernum
Costin Leau
Dimitris Athanasiou
Nhat
Alexander Reelsen
Tanguy Leroux
Nik Everett
jaymode
Tim Brooks
Martijn van Groningen
Jason Tedor
David Kyle