-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
Force class load on UserRequest, see JENKINS-19445 #82
Conversation
This is a workaround to force class load of any class. This helps prevent deadlock on windows nodes when using JNA and Subversion. Use property hudson.remoting.RemoteClassLoader.force to name the class to load. Ideally this forced load should happen earlier on the startup, however the classloader isn't available.
Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests. |
// Allow forcibly load of a class, allows to workaround: | ||
// @See https://issues.jenkins-ci.org/browse/JENKINS-19445 | ||
// @Related https://issues.tmatesoft.com/issue/SGT-451 | ||
final String clazz = System.getProperty(RemoteClassLoader.class.getName() + ".force", null); |
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 would vote for initializing it once as a static variable.
I don't see how the dynamic provisioning may help, but it decreases the performance a bit
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.
This is the only point we are certain to have the same ClassLoader with the same rules. Not sure how to obtain the same ClassLoader from a static block. We checked all the flow from Launcher to here, as the only point were it would be safe, and early enough to prevent the blockage.
Fixes based on code review of pull-request: jenkinsci#82
Fix Logger.log() invocation: needs Object[], not vargs.
👍 |
My action item is to document it somehow |
Is this some sort of bug in JNA? Is there a filed issue for that? |
Yes @jglick, it's filed here: |
…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)
This is a workaround to force class load of any class. This helps prevent deadlock on windows nodes when using JNA and Subversion.
Use property hudson.remoting.RemoteClassLoader.force to name the class to load. Ideally this forced load should happen earlier on the startup, however the classloader isn't available.
link: https://issues.jenkins-ci.org/browse/JENKINS-19445