The changes the way the Elasticsearch plugin module gets the cpp code when running the bundlePlugin task. Instead of manually going into the cpp builds output and grabbing the folders it depends on the buildZip task of the :cpp project and grabs the resource that task builds. This means that it does not matter if the cpp buildZip task is changed as long as it results in a zip being generated.
Original commit: elastic/x-pack-elasticsearch@257e5df2e7
Make sure CountDownLatch gets removed when it is no longer needed
Also add CountDownLatch is it is missing when we ack a flush id,
we may ack before we wait for it
Original commit: elastic/x-pack-elasticsearch@83a993b9ad
* Persist DataCounts every 10 seconds from a thread pool scheduled task.
Also rework the isReportingBoundary function changing the function as the boundary changes
* Remove overloaded constructors from StatusReporter and DummyStatusReporter
* Persist dataCounts in a background thread from the status reporter
* Use generic threadpool
Original commit: elastic/x-pack-elasticsearch@f00c1067aa
* Renamed REST path parameters to snake case.
And added missing parameter descriptions
* Document endpoint which accept body parameters
* Endpoints that support body parameters must also accept POST
Original commit: elastic/x-pack-elasticsearch@2cad2e8af6
The problem is that the Java security manager can open the pipe and then
quickly close it, leading to a need to reconnect from the C++ side.
Original commit: elastic/x-pack-elasticsearch@772b57f443
it can happen we encounter more then one cluster states with no usage index and causing this class to send two or more create index requests, but only one request will succeed.
Original commit: elastic/x-pack-elasticsearch@524a1dda61
Also moved all creation logic that is required to run at cluster startup into PrelertInitializationService.
Original commit: elastic/x-pack-elasticsearch@453ba3efa3
* Add result_type field to bucket
* Query and delete buckets/records by result_type
* Add a filter to the ElasticsearchBatchedDocumentsIterator subclasses for result_type:bucket
* De-type Influencers, BucketInfluencers and Category Definitions
* Revert de-typing CategoryDefinition
* Resolve merge errors after rebase
Original commit: elastic/x-pack-elasticsearch@65605432e8
In c++ the results are built all together under a bucket hierarchy.
This buckets was written out and java would read it and split the
bucket into its parts: the bucket itself, its records and its
influencers.
During the migration, the bucket started being persisted as a whole,
including its records and influencers.
This commit is changing this by modifying the way results are written
in c++. This way, the java and c++ results writing/reading are in sync.
To achieve this, the change involved writing records and influencers as
top level results from c++. In addition, they are written as an array
object in order to allow the java side to persist them in a bulk
request.
* Fix bucket counting in results processor
Original commit: elastic/x-pack-elasticsearch@feadf3f887
Elasticsearch will now attempt to spawn a controller daemon called simply
`controller` when it starts up, but ours was called `prelert_controller`.
For consistency it makes sense to remove the prefix from all our programs.
Original commit: elastic/x-pack-elasticsearch@d06714b231
* Make close job a master node action
The close job action now:
- Is a master node action
- Sets the job status to CLOSING
- Waits for the job status to change to CLOSED before it responds
JobLifeCycleService picks up on a job status change to CLOSING and
closes the job. At the end, it sets the job status to CLOSED.
* Assert job status is closed after close in integration test
This also correctly passes an ActionListener to JobManager.setJobStatus
in order to ensure the job status request has completed and to properly
propagate failures.
Original commit: elastic/x-pack-elasticsearch@1546c77fca
The PID used needs to be the PID of autodetect's parent proecss. The parent
is of course the controller daemon rather than the JVM.
Original commit: elastic/x-pack-elasticsearch@607481e1e2