Skip to content

Forward port #85000 and #84838 to 8.1 branch#85040

Merged
martijnvg merged 2 commits intoelastic:8.1from
martijnvg:forwardport_85000_and_84838_to_8.1
Mar 16, 2022
Merged

Forward port #85000 and #84838 to 8.1 branch#85040
martijnvg merged 2 commits intoelastic:8.1from
martijnvg:forwardport_85000_and_84838_to_8.1

Conversation

@martijnvg
Copy link
Copy Markdown
Member

Forward port #85000 (Revert enrich cache lookup optimisation ) and #84838 (CompoundProcessor should also catch exceptions when executing a processor) to 8.1 branch.

Forwardporting elastic#85000 to master branch.

This PR reverts the optimisation that was added via elastic#77259.

This optimisation cleverly ensures no duplicate searches happen if multiple threads concurrently execute the same search.
However there are issues with the implementation that cause issues like elastic#84781. The optimisation make use of CompletableFuture and in this case we don't check whether the result has completed exceptionally. Which causes the callback not being invoked and this leads to bulk request not being completed and hanging around.

The ingest framework due to its asynchronous nature is already complex and adding CompletableFuture into the mix makes debugging these issues very time consuming. This is the main reason why we like to revert this commit.
…ssor (elastic#84838) (elastic#85035)

Currently, CompoundProcessor does not catch Exception and
if a processor throws an error and a method higher in the
call stack doesn't catch the exception then pipeline execution
stalls and bulk requests may not complete.

Usually these exceptions are caught by IngestService#executePipelines(...) method,
but when a processor executes async (for example: enrich processor) and the thread
that executes enrich is no longer the original write thread then there is no logic
that deals with failing pipeline execution and cleaning resources up. This then leads
to memory leaks.

Closes elastic#84781

Also change how 'pipeline doesn't exist' error is thrown in TrackingResultProcessor.

With the change to CompoundProcessor thrown exceptions are caught and delegated to handler.
SimulateExecutionService in verbose mode ignores exceptions delegated to its handler, since
it assumes that processorResultList contains the result (successful or not successful) of every
processor in the pipeline.

In case TrackingResultProcessor for PipelineProcessor couldn't find the mentioned pipeline then
it just throws an error without updating the processorResultList. This commit addresses that.
@martijnvg martijnvg added backport auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) v8.1.2 :Distributed/Ingest Node Execution or management of Ingest Pipelines labels Mar 16, 2022
@martijnvg martijnvg merged commit 0bb4c2b into elastic:8.1 Mar 16, 2022
@elasticmachine elasticmachine added the Team:Data Management (obsolete) DO NOT USE. This team no longer exists. label Mar 16, 2022
@elasticmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/es-data-management (Team:Data Management)

@martijnvg martijnvg deleted the forwardport_85000_and_84838_to_8.1 branch March 16, 2022 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) backport :Distributed/Ingest Node Execution or management of Ingest Pipelines Team:Data Management (obsolete) DO NOT USE. This team no longer exists. v8.1.2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants