[JENKINS-68122] Avoid deadlock involving RingBufferLogHandler.LogRecordRef class loading (III)

[jglick]

See JENKINS-68122. Amends #6018 + #6044. Alternative to #6444 & #6446.

Effectiveness still being validated. Variant of suggestion by @roband7 (hope the GitHub and Jira ids align). I think the problem is in

jenkins/core/src/main/java/hudson/slaves/SlaveComputer.java

Lines 1062 to 1092 in 71d5dd5

	/**
	* Puts the {@link #SLAVE_LOG_HANDLER} into a separate class so that loading this class
	* in JVM doesn't end up loading tons of additional classes.
	*/
	static final class LogHolder {
	/**
	* This field is used on each agent to record logs on the agent.
	*/
	static RingBufferLogHandler SLAVE_LOG_HANDLER;
	}
	private static class SlaveInitializer extends MasterToSlaveCallable<Void, RuntimeException> {
	final int ringBufferSize;
	SlaveInitializer(int ringBufferSize) {
	this.ringBufferSize = ringBufferSize;
	}
	@Override
	@SuppressFBWarnings(value = "ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD", justification = "field is static for the reason explained in the Javadoc for LogHolder")
	public Void call() {
	SLAVE_LOG_HANDLER = new RingBufferLogHandler(ringBufferSize);
	// avoid double installation of the handler. Inbound agents can reconnect to the controller multiple times
	// and each connection gets a different RemoteClassLoader, so we need to evict them by class name,
	// not by their identity.
	for (Handler h : LOGGER.getHandlers()) {
	if (h.getClass().getName().equals(SLAVE_LOG_HANDLER.getClass().getName()))
	LOGGER.removeHandler(h);
	}
	LOGGER.addHandler(SLAVE_LOG_HANDLER);

jenkinsci/remoting#527 might offer a hotfix for those who cannot easily change the core (controller) version.

Proposed changelog entries

• Avoid a deadlock between agent class loading and logging.

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

marked as on-hold till confirmed it works :)

[roband7]

I can confirm this patch works for us. Been running 2.332.2 + this patch on our main Jenkins server today. No hangs, and no other issues.

[basil]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!