Bug: when raw-streams are used, ensure system streams are set up (#11303) #11310
+12
−3
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
…che#11303) When `--raw-streams` is used (especially when combined with options like `--quiet` and `-DforceStdout`) there is no guarantee that anything touches terminal. Hence, in case of embedded executor it is quite possible that cached/warm code arrives quickly at the place that would do system out **before** the thread with `FastTerminal` finishes system install. In other words, when `--raw-streams` are used, we cannot guarantee that system streams are already properly set up. This PR changes that, and makes sure (by triggering a dummy call to terminal), at the cost of "jline3 install lag" for CLI invocation. OTOH, this lag in case of embedded executors does not exists (it exists only on first invocation). My suspicion that this is the cause of IT instability issues, when Verifier used Toolbox output ends up on Surefire stdout and not on "grabbed" output, as simply streams are not yet set up properly. Also, this usually happens "around the second half" of ITs, when cached and warmed up embedded instance is already uber optimized.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When
--raw-streamsis used (especially when combined with options like--quietand-DforceStdout) there is no guarantee that anything touches terminal. Hence, in case of embedded executor it is quite possible that cached/warm code arrives quickly at the place that would do system out before the thread withFastTerminalfinishes system install.In other words, when
--raw-streamsare used, we cannot guarantee that system streams are already properly set up. This PR changes that, and makes sure (by triggering a dummy call to terminal), at the cost of "jline3 install lag" for CLI invocation. OTOH, this lag in case of embedded executors does not exists (it exists only on first invocation).My suspicion that this is the cause of IT instability issues, when Verifier used Toolbox output ends up on Surefire stdout and not on "grabbed" output, as simply streams are not yet set up properly. Also, this usually happens "around the second half" of ITs, when cached and warmed up embedded instance is already uber optimized.
Backport of bb94de0