Class loading deadlock between PermalinkProjectAction.Permalink & PeepholePermalink

[jglick]

A functional test in CloudBees CI was observed to hang occasionally. Inspecting the thread dump revealed an apparent class loading deadlock. It is unknown whether this would affect production scenarios.

Fundamentally the problem is the use of static final fields for non-constant expressions. It would be incompatible to just delete these fields, unfortunately; plugins using them include for example

• build-symlink
• build-alias-setter
• copyartifact
• run-selector
• infradna-backup (CloudBees CI)

As noted here it is not always clear how to solve these problems compatibly.

Testing done

Test usually deadlocks. Thread dump after 7dee8b2

"main" #1 prio=5 os_prio=0 cpu=350.37ms elapsed=13.59s tid=0x00007f9848016000 nid=0x958f in Object.wait()  [0x00007f984f0b3000]
   java.lang.Thread.State: RUNNABLE
	at jenkins.model.PeepholePermalinkTest.classLoadingDeadlock(PeepholePermalinkTest.java:42)
	at …

"Thread-1" #16 prio=5 os_prio=0 cpu=0.99ms elapsed=13.17s tid=0x00007f9848b62800 nid=0x95ab in Object.wait()  [0x00007f981c8f4000]
   java.lang.Thread.State: RUNNABLE
	at hudson.model.PermalinkProjectAction$Permalink.<clinit>(PermalinkProjectAction.java:114)
	at jenkins.model.PeepholePermalinkTest.lambda$classLoadingDeadlock$0(PeepholePermalinkTest.java:39)
	at jenkins.model.PeepholePermalinkTest$$Lambda$328/0x000000084010d040.run(Unknown Source)
	at java.lang.Thread.run([email protected]/Thread.java:829)

Proposed changelog entries

• Preventing a deadlock that can occur when loading PermalinkProjectAction.Permalink.

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

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. 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]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!