-
-
Notifications
You must be signed in to change notification settings - Fork 272
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
[FIXED JENKINS-34213] Ensure that the unexporter cleans up whatever it can each sweep #81
Conversation
…t can each sweep
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
* you can reduce GC pressure by discarding the origin call-site stack traces and setting this system | ||
* property. | ||
*/ | ||
private static final boolean retainOrigin = |
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.
Unrelated, but it seems to be a useful addition
FYI my stress testing of this fell over into Full GCs... I may need to refine further |
Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests. |
…nce collection for better stability - We want to report on these things only if they are an issue. Logging of the actual stats should be below the radar of the users using a default logger level of `INFO` provided that the Unexporter is not doing much - When the Unexporter is busy (i.e. the m1 rate is > 100/sec) then we should start reporting at `INFO` - In the event that there is sustained high levels of work, we should alert the user and recommend turning off the stack traces to reduce GC pressure - My stress testing revealed that under very heavy load it is better to batch the removal and then batch the clean-up even if this batching means that the sweeps are not as frequent.
@oleg-nenashev should be ready now! I'm not seeing this one fall over into full GCs... of course will leave it running some more ;-) |
…ng for close and close Spotted in https://jenkins.ci.cloudbees.com/job/libraries/job/remoting/177/console
The three most common programming errors are: - Off by one errors - Copy and paste errors
… an actual real bug
🐝 |
2 similar comments
🐝 |
🐝 |
@reviewbybees done |
@jenkins/code-reviewers |
@jenkinsci/code-reviewers |
This pull request has completed our internal processes and we now respectfully request the maintainers of this repository to consider our proposal contained within this pull request for merging. |
Ready to be integrated. |
Changes: * [JENKINS-34213](https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (jenkinsci/remoting#81) * [JENKINS-19445](https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (jenkinsci/remoting#81) * [JENKINS-34808](https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (jenkinsci/remoting#68)
…oting to 2.59. (#2344) * [JENKINS-19445, JENKINS-34213, JENKINS-34808] Bump remoting to 2.58. Changes: * [JENKINS-34213](https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (jenkinsci/remoting#81) * [JENKINS-19445](https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (jenkinsci/remoting#81) * [JENKINS-34808](https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (jenkinsci/remoting#68) * [JENKINS-34121] - Upgrade remoting to 2.59
…oting to 2.59 Changes: 2.58: * [JENKINS-34213](https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (jenkinsci/remoting#81) * [JENKINS-19445](https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (jenkinsci/remoting#82) * [JENKINS-34808](https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (jenkinsci/remoting#68) 2.59: * [JENKINS-34819](https://issues.jenkins-ci.org/browse/JENKINS-34819) - Allow disabling the remoting protocols individually. Works around issues like [JENKINS-34121](https://issues.jenkins-ci.org/browse/JENKINS-34121) (jenkinsci/remoting#83)
…oting to 2.59. (#2344) * [JENKINS-19445, JENKINS-34213, JENKINS-34808] Bump remoting to 2.58. Changes: * [JENKINS-34213](https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (jenkinsci/remoting#81) * [JENKINS-19445](https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (jenkinsci/remoting#81) * [JENKINS-34808](https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (jenkinsci/remoting#68) * [JENKINS-34121] - Upgrade remoting to 2.59 (cherry picked from commit 409438f)
@reviewbybees