The instance is facing performance issues and in the slow-requests it can be observed the following thread
Username: user1 Referer: http://localhost:8080/job/JOB1/configure ... URL: http://localhost:8080/job/JOB1/descriptorByName/org.jfrog.hudson.maven3.ArtifactoryMaven3Configurator/fillCredentialsIdItems Locale: en_US ... "Handling POST /job/JOB1/descriptorByName/org.jfrog.hudson.generic.ArtifactoryGenericConfigurator/fillCredentialsIdItems from 10.249.50.45 : RequestHandlerThread[#1465]" Id=2360516 RUNNABLE at java.lang.SecurityManager.getClassContext(Native Method) at javax.crypto.JceSecurityManager.getCryptoPermission(JceSecurityManager.java:102) at javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2587) at javax.crypto.Cipher.initCryptoPermission(Cipher.java:700) at javax.crypto.Cipher.chooseProvider(Cipher.java:863) at javax.crypto.Cipher.init(Cipher.java:1396) at javax.crypto.Cipher.init(Cipher.java:1327) at jenkins.security.CryptoConfidentialKey.encrypt(CryptoConfidentialKey.java:81) ...
- CloudBees CI (CloudBees Core) on modern cloud platforms - Managed Master
- CloudBees CI (CloudBees Core) on traditional platforms - Client Master
- CloudBees Jenkins Enterprise - Managed Master
- CloudBees Jenkins Platform - Client Master
- CloudBees Jenkins Distribution
- Jenkins LTS
It appears that the instance is configured to use the restricted strength (export) crypto via the JceSecurityManager, so the lookup seems to take a long time. Using the unlimited strength crypto policy set, it won’t perform this (slow) check so it should solve the issue.
Unlimited strength crypto was set as the default in Java 8u161, so updating to this JRE or later should also fix the issue.