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

Do not cancel subscription on BlockingIterable#hasNext(long, TimeUnit) #3128

Merged
merged 2 commits into from
Dec 16, 2024

Conversation

daschl
Copy link
Contributor

@daschl daschl commented Dec 5, 2024

This makes sure that if this method, or indirectly next(long, TimeUnit) is called and times out, the caller is able to retry the operation and also the upstream source will not be cancelled.

In the context of a BlockingStreaming server, this means that if a timeout is thrown on the incoming request, the outgoing response can still be modified since the underlying socket will not be immediately closed.

It also aligns the semantics with Single#toFuture where a blocking get with a timeout on the future also does not cancel the upstream Single.

A (temporary) system property is introduced which allows to fall back to the old behavior should incompatibilities be discovered in the wild.

A note for the reader who wonders how to close the subscription now: the close() method always did cancel the subscription and continues to do so. To make sure forEach also adheres to the iterator contract it uses it is now wrapped in try-with-resource.

This makes sure that if this method, or in extend next(long, TimeUnit) is
called and times out, the caller is able to retry the operation and also
the upstream source will not be cancelled.

In the context of a Blocking Streaming server, this means that if a timeout
is thrown on the incoming request, the outgoing response can still be modified
since the underlying socket will not be immediately closed.

It also aligns the semantics with Single#toFuture where a blocking get with
a timeout on the future also does not cancel the upstream Single.

A (temporary) system property is introduced which allows to fall back to the
old behavior should incompatibilities be discovered in the wild.

A note for the reader who wonders how to close the subscription now: the close()
method always did cancel the subscription and continues to do so.
@daschl daschl requested a review from idelpivnitskiy December 5, 2024 10:18
@daschl daschl marked this pull request as ready for review December 6, 2024 09:23
@@ -72,6 +72,12 @@ public BlockingIterator<T> iterator() {
}

private static final class SubscriberAndIterator<T> implements Subscriber<T>, BlockingIterator<T> {
/**
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be worth adding that this is false by default, ie not enabled.

Copy link
Contributor

@mgodave mgodave left a comment

Choose a reason for hiding this comment

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

You presented this offline, I think this is the correct behavior.

@daschl daschl merged commit 85fd41b into apple:main Dec 16, 2024
11 checks passed
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.

3 participants