-
Notifications
You must be signed in to change notification settings - Fork 910
Stop publishing after Content-Length bytes #539
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
Conversation
subscriber.onNext(content); | ||
written += newLimit; | ||
|
||
if (!shouldContinuePublishing()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to cancel or can we just call on complete?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should also cancel the subscription to so the adapted publisher can do any cleanup if it wanted to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can just do that in onComplete right?
If a Publisher signals either onError or onComplete on a Subscriber, that Subscriber’s Subscription MUST be considered cancelled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I might be confused but since our adapter sits between the streamed request subscriber and the user supplied request content publisher, we need to cancel
the subscription to the content publisher and call onComplete
the streamed request right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was reading again and found this so this looks right to me.
The intent of this rule is to establish that Subscribers cannot just throw Subscriptions away when they are no longer needed, they have to call cancel so that resources held by that Subscription can be safely, and timely, reclaimed. An example of this would be a Subscriber which is only interested in a specific element, which would then cancel its Subscription to signal its completion to the Publisher.
subscriber.onNext(content); | ||
written += newLimit; | ||
|
||
if (!shouldContinuePublishing()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was reading again and found this so this looks right to me.
The intent of this rule is to establish that Subscribers cannot just throw Subscriptions away when they are no longer needed, they have to call cancel so that resources held by that Subscription can be safely, and timely, reclaimed. An example of this would be a Subscriber which is only interested in a specific element, which would then cancel its Subscription to signal its completion to the Publisher.
…9c1a9443 Pull request: release <- staging/79945b4c-f3b4-41ba-ac45-1d319c1a9443
Stop publishing after Content-Length bytes
Fixes #460
Description
Stop publishing after Content-Length bytes
Fixes #460
Motivation and Context
Fix #460
Testing
mvn clean install
with new unit test.Screenshots (if appropriate)
Types of changes
Checklist
mvn install
succeedsLicense