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

RetryingHttpRequesterFilter use original Publisher avoid SOOE #2666

Merged
merged 2 commits into from
Aug 11, 2023

Conversation

Scottmitch
Copy link
Member

Motivation:
RetryingHttpRequesterFilter uses the request across retry operations. The request's Publisher state is shared across retries and operators applied via transformMessageBody will therefore be reapplied on each retry. This typically isn't desirable from a semantics perspective but may also lead to StackOverflowException if enough retries are attempted.

Modifications:

  • RetryingHttpRequesterFilter should reuse the original Publisher for request payload body on each retry attempt.

@Scottmitch Scottmitch force-pushed the retry_req_pub branch 3 times, most recently from 47d61c8 to 62b4017 Compare August 2, 2023 13:01
Copy link
Member

@idelpivnitskiy idelpivnitskiy left a comment

Choose a reason for hiding this comment

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

Good idea, it should work!

final Publisher<Object> originalMessageBody = request.messageBody();
Single<StreamingHttpResponse> single = Single.defer(() -> (mayReplayRequestPayload ?
delegate.request(request.transformMessageBody(messageBodyDuplicator(originalMessageBody))) :
delegate.request(request.transformMessageBody(p -> originalMessageBody))
Copy link
Member

Choose a reason for hiding this comment

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

When mayReplayRequestPayload == false, we don't need to do anything with originalMessageBody. Consider storing the reference and using defer only when mayReplayRequestPayload == true.

Copy link
Member Author

@Scottmitch Scottmitch Aug 2, 2023

Choose a reason for hiding this comment

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

When mayReplayRequestPayload == false, we don't need to do anything with originalMessageBody.

The unit test demonstrates the problem exists regardless of mayReplayRequestPayload. In either case if we don't restore the original publisher we will keep appending operators and eventually SOOE.

@Scottmitch Scottmitch marked this pull request as ready for review August 2, 2023 22:44
@Scottmitch Scottmitch marked this pull request as draft August 9, 2023 06:22
@Scottmitch Scottmitch force-pushed the retry_req_pub branch 3 times, most recently from 643a54e to f96202c Compare August 9, 2023 06:29
Motivation:
RetryingHttpRequesterFilter uses the request across retry operations.
The request's Publisher state is shared across retries and operators
applied via transformMessageBody will therefore be reapplied on
each retry. This typically isn't desirable from a semantics perspective
but may also lead to StackOverflowException if enough retries are
attempted.

Modifications:
- RetryingHttpRequesterFilter should reuse the original Publisher
for request payload body on each retry attempt.
@Scottmitch Scottmitch merged commit 1d05447 into apple:main Aug 11, 2023
15 checks passed
@Scottmitch Scottmitch deleted the retry_req_pub branch August 11, 2023 16:37
Copy link
Member

@idelpivnitskiy idelpivnitskiy left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -37,7 +37,7 @@ public Single<StreamingHttpResponse> handle(final HttpServiceContext ctx,
final StreamingHttpRequest request,
final StreamingHttpResponseFactory responseFactory) {
return request.toRequest().flatMap(req -> fromCallable(() -> original.handle(
ctx, req, ctx.responseFactory())).map(HttpResponse::toStreamingResponse));
ctx, req, ctx.responseFactory())).map(HttpResponse::toStreamingResponse).shareContextOnSubscribe());
Copy link
Member

Choose a reason for hiding this comment

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

Good catch!

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.

None yet

3 participants