opensearch-project / opensearch-project/data-prepper

Run Peer Forwarder requests in parallel

Open
#2,118 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
374
Forks
354
Avg merge
3d 18h
Merged PRs (30d)
8

Description

Is your feature request related to a problem? Please describe.

The following code snippet is where peer-forwarder sends records to a peer server. It is running in a loop.

https://github.com/opensearch-project/data-prepper/blob/590ee21fe2c4ceb8e99626d87f5672919d7ca6a5/data-prepper-core/src/main/java/org/opensearch/dataprepper/peerforwarder/RemotePeerForwarder.java#L97-L98

Each call must perform the following:

  1. Get the correct WebClient
  2. Serialize the JSON
  3. Make the HTTP request to the remote peer
  4. Increment the counter

Step 3 is a remote call which will wait on the remote server. Because this happens in a loop, each remove server is called one at a time.

Describe the solution you'd like

The peer-forwarder should call all the remote peer servers at the same time. They can make asynchronous requests and then wait on all the complete.

Describe alternatives you've considered (Optional)

I'm interested in a concept for peer-forwarder outgoing buffers as well. But, this would be a little more complicated. The current proposal could be a simpler solution to help with peer-forwarder performance.

Additional context

N/A

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in data-prepper-core/src/main/java/org/opensearch/dataprepper/peerforwarder/RemotePeerForwarder.java at lines 97-98, tracing WebClient selection, JSON serialization, the remote request, and counter increment. Confirm how the current loop waits on each peer, then define done as initiating requests concurrently and waiting for all of them to complete.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
distributed-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.