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

http: support readable hwm in IncomingMessage #30135

Merged
merged 1 commit into from
Oct 30, 2019
Merged

Conversation

cjihrig
Copy link
Contributor

@cjihrig cjihrig commented Oct 26, 2019

This commit causes http.IncomingMessage instances to set their readableHighWaterMark value the same value used in the underlying socket.

FWIW, http.OutgoingMessage already uses the socket to set its writableHighWaterMark.

Fixes: #30107

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Oct 26, 2019
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

nodejs-github-bot commented Oct 26, 2019

@cjihrig
Copy link
Contributor Author

cjihrig commented Oct 29, 2019

Before I land this, is anyone opposed to it landing as semver-patch? If we treat it as a semver-major, then it would require one more TSC reviewer.

This commit causes http.IncomingMessage instances to set their
readableHighWaterMark value the same value used in the underlying
socket.

PR-URL: nodejs#30135
Fixes: nodejs#30107
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Yongsheng Zhang <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
@cjihrig cjihrig merged commit 11276af into nodejs:master Oct 30, 2019
@cjihrig cjihrig deleted the rhwm branch October 30, 2019 14:33
targos pushed a commit that referenced this pull request Nov 5, 2019
This commit causes http.IncomingMessage instances to set their
readableHighWaterMark value the same value used in the underlying
socket.

PR-URL: #30135
Fixes: #30107
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Yongsheng Zhang <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
@targos targos mentioned this pull request Nov 5, 2019
@targos targos added the semver-minor PRs that contain new features and should be released in the next minor version. label Nov 8, 2019
MylesBorins pushed a commit that referenced this pull request Jan 12, 2020
This commit causes http.IncomingMessage instances to set their
readableHighWaterMark value the same value used in the underlying
socket.

PR-URL: #30135
Fixes: #30107
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Yongsheng Zhang <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
BethGriggs pushed a commit that referenced this pull request Feb 6, 2020
This commit causes http.IncomingMessage instances to set their
readableHighWaterMark value the same value used in the underlying
socket.

PR-URL: #30135
Fixes: #30107
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Yongsheng Zhang <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Feb 8, 2020
@ronag
Copy link
Member

ronag commented Jan 6, 2021

This seems a bit strange to me. Won't the effective buffering now be 2 * socket.readableHighWaterMark or socket.readableHighWaterMark + 16k (depending on whether socket.consume is used)? I kind of think highWaterMark on IncomingMessage should be 0? @mcollina wdyt?

@mcollina
Copy link
Member

mcollina commented Jan 7, 2021

I'm generically ok in more buffering, I don't see a problem with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. http Issues or PRs related to the http subsystem. semver-minor PRs that contain new features and should be released in the next minor version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Request: Option to configure highWaterMark of HTTP response
9 participants