Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aggregator processor should evaluate aggregate_when condition before forwarding events to remote peer #4004

Merged
merged 5 commits into from
Jan 25, 2024

Conversation

kkondaka
Copy link
Collaborator

@kkondaka kkondaka commented Jan 23, 2024

Description

Aggregate processor support aggregate_when option which may evaluate to false to some events. But the current remote forwarder interface evaluates this condition after an event is forwarded to a remote peer which is unnecessary. The condition can be evaluated locally on a forwarding node before actually forwarding the event.

Modified the remote forwarding interface to allow local evaluation of events before forwarding events to remote peer.

Resolves #3996

Issues Resolved

Resolves #3996

Check List

  • [ X] New functionality includes testing.
  • New functionality has a documentation issue. Please link to it in this PR.
    • New functionality has javadoc added
  • [ X] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

…forwarding events to remote peer

Signed-off-by: Krishna Kondaka <krishkdk@dev-dsk-krishkdk-2c-bd29c437.us-west-2.amazon.com>
@@ -79,7 +80,9 @@ private PeerForwardingProcessorDecorator(final PeerForwarder peerForwarder, fina

@Override
public Collection<Record<Event>> execute(final Collection<Record<Event>> records) {
final Collection<Record<Event>> recordsToProcessOnLocalPeer = peerForwarder.forwardRecords(records);
final Collection<Record<Event>> recordsToProcess = ((RequiresPeerForwarding)innerProcessor).applicableEventsForPeerForwarding(records);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the end of this method, we return:

return innerProcessor.execute(recordsToProcessLocally);

The collection returned by the processor will be the input into the next processor. With this PR, the returned collection is going to be inaccurate when aggregate_when is present. The pipeline author still wants to process those events in downstream processors.

We need something like the following. I'll use + for set union and - for set difference. This should convey the idea, but these are not valid set operators in Java, so you'll need a little modification. Also, Collection is not necessarily a Set.

return innerProcessor.execute(recordsToProcessLocally) + (records - recordsToProcess);

We'll definitely need a unit test here.

It would be ideal to also have a core integration test.

final Collection<Record<Event>> recordsOut = new ArrayList<>();
for (Record<Event> record: records) {
Event event = record.getData();
if (expressionEvaluator.evaluateConditional(whenCondition, event)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's share the same logic here as we use in the execute method to ensure they remain consistent.

Maybe you could make a method that evaluates the conditional in both.

private boolean isEventApplicable(Record<Event> record)

}

@Test
void testRequiresPeerForwardingTest() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for adding this test!

Krishna Kondaka added 2 commits January 24, 2024 02:29
Signed-off-by: Krishna Kondaka <krishkdk@dev-dsk-krishkdk-2c-bd29c437.us-west-2.amazon.com>
Signed-off-by: Krishna Kondaka <krishkdk@dev-dsk-krishkdk-2c-bd29c437.us-west-2.amazon.com>
@dlvenable
Copy link
Member

@kkondaka , I see some test failures:

> Task :data-prepper-plugins:aggregate-processor:test

> Task :data-prepper-core:test

PeerForwardingProcessingDecoratorTest > WithRegisteredPeerForwarder > PeerForwardingProcessingDecorator_execute_should_forwardRecords_with_correct_values() FAILED
    org.mockito.exceptions.misusing.PotentialStubbingProblem at PeerForwardingProcessingDecoratorTest.java:140

PeerForwardingProcessingDecoratorTest > WithRegisteredPeerForwarder > PeerForwardingProcessingDecorator_execute_should_receiveRecords() FAILED
    org.mockito.exceptions.misusing.PotentialStubbingProblem at PeerForwardingProcessingDecoratorTest.java:163
> Task :data-prepper-core:test FAILED
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.mockito.internal.util.reflection.ReflectionMemberAccessor (file:/home/runner/.gradle/caches/modules-2/files-2.1/org.mockito/mockito-core/3.11.2/bb97012477172d7c04ff2193e31fcb38dd171879/mockito-core-3.11.2.jar) to constructor java.lang.Runtime()
WARNING: Please consider reporting this to the maintainers of org.mockito.internal.util.reflection.ReflectionMemberAccessor

Krishna Kondaka added 2 commits January 24, 2024 22:50
Signed-off-by: Krishna Kondaka <krishkdk@dev-dsk-krishkdk-2c-bd29c437.us-west-2.amazon.com>
Signed-off-by: Krishna Kondaka <krishkdk@dev-dsk-krishkdk-2c-bd29c437.us-west-2.amazon.com>
Copy link
Member

@dlvenable dlvenable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making this improvement!

@dlvenable dlvenable merged commit 2be8166 into opensearch-project:main Jan 25, 2024
47 checks passed
@kkondaka kkondaka deleted the peer-forwarder-opt branch May 13, 2024 05:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow peer forwarder to skip sending events to remote peer
3 participants