child_process: change the defaults maxBuffer size by koh110 · Pull Request #27179 · nodejs/node (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation21 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

koh110

I changed the defaults for all the maxBuffer sizes to a much larger value.

Refs: #23027

Requested in #23027 (review) by @mcollina

Checklist

@koh110

@sam-github

Strikes me as an enormously large value, but I don't have a good feel for what value is reasonable. This could lead to sharply increased memory usage for some use cases... but then, if people care, the maxBuffer option should be used to set limits appropriate to the use.

bnoordhuis

Choose a reason for hiding this comment

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

See #9829 and #11196, notably #9829 (comment) - it's been discussed before.

Changing the default isn't completely out of the question but since it's intended as a containment mechanism for runaway processes, increasing it 320x from 200k to 64M seems like a tremendously bad idea.

@mcollina

Changing the default isn't completely out of the question but since it's intended as a containment mechanism for runaway processes, increasing it 320x from 200k to 64M seems like a tremendously bad idea.

We had Infinity before. This is smaller. From a user point of view, if we are executing a binary and it suddenly got output truncated because of a Node.js update, it would be a bad user experience.

@koh110

@sam-github

I doubt that citgm would find these things, its likely going to only show up at load (not that more testing is bad).

But I think that exec and spawnSync should be set same value.

Definitely.

I like the 1 meg suggestion (#9829 (comment)).

Its really hard to get these numbers right, I'd also be OK with no limit, or a child_process.DEFAULT_MAX_BUFFER that was writable.

@sam-github

To follow on, 1meg is only 5 times larger, which seems to deal with output that is larger than a normal hand-created text file, more log-file size. Bigger enough it may cover some more use cases, but not so big its useless as protection against a run-away process, and not so controversial as removing all limits, and letting the only limit be node's ability to allocate memory (aka "infininite").

@koh110

I like this suggestion too. I think It is suitable.

I like the 1 meg suggestion

@bnoordhuis How about this idea?

maxBuffer should not be setted Infinity for run-away process. But I think it is necessary to set maxBuffer to a higher value, because changing value of spawnSync give big impact.

@bnoordhuis

1M seems like a good middle ground.

@koh110

@koh110

sam-github

BridgeAR

@BridgeAR BridgeAR added the semver-major

PRs that contain breaking changes and should be released in the next major version.

label

Apr 16, 2019

@BridgeAR

Changing a default should likely be semver-major.

@sam-github

Changing a default should likely be semver-major.

I'm on the fence about that. Its increasing the maxBuffer, is it a breaking change that some apps will stop failing? But then, it will use more memory. I guess there is no hurry to land in 12.x, it'll be in 13.x in a month.

@koh110

I think it should be landed in 12.x. Because, it will have an impact on developers who are using over 200 * 1024.
I think that we should decrease impact with this version up.

bnoordhuis

Choose a reason for hiding this comment

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

LGTM. Semver-major seems appropriate.

@sam-github

@BethGriggs @nodejs/tsc Should this land in 12.x? Its not a complex change, so I think its low risk of instability, even though it is late in 12.x rc cycle.

@nodejs-github-bot

@BethGriggs

@sam-github

@mcollina @nodejs/tsc: this requires 2 TSC approvals, it currently has 0

targos

BethGriggs

mhdawson

Choose a reason for hiding this comment

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

LGTM

@mhdawson

@sam-github

sam-github pushed a commit that referenced this pull request

Apr 17, 2019

@koh110 @sam-github

PR-URL: #27179 Refs: #23027 Reviewed-By: Ben Noordhuis info@bnoordhuis.nl Reviewed-By: Sam Roberts vieuxtech@gmail.com Reviewed-By: Ruben Bridgewater ruben@bridgewater.de Reviewed-By: Michaël Zasso targos@protonmail.com Reviewed-By: Beth Griggs Bethany.Griggs@uk.ibm.com Reviewed-By: Michael Dawson michael_dawson@ca.ibm.com

BethGriggs added a commit that referenced this pull request

Apr 22, 2019

@BethGriggs

Notable changes:

PR-URL: #26930

This was referenced

Apr 23, 2019

Reviewers

@sam-github sam-github sam-github approved these changes

@bnoordhuis bnoordhuis bnoordhuis approved these changes

@targos targos targos approved these changes

@BethGriggs BethGriggs BethGriggs approved these changes

@BridgeAR BridgeAR BridgeAR approved these changes

@mhdawson mhdawson mhdawson approved these changes

@mcollina mcollina Awaiting requested review from mcollina

Labels

child_process

Issues and PRs related to the child_process subsystem.

semver-major

PRs that contain breaking changes and should be released in the next major version.