-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins Version 2.462.1
P4 Plugin Version1.16.0
P4 Server version: P4D/LINUX26X86_64/2023.1/2576871 (2024/03/25)
Recently pipelines on our Jenkins controllers have been getting stuck while processing p4 change sets.
A heap dump shows the threads for the impacted jobs waiting deep within a stack trace starting from a call to P4ChangeParser.parse(Run, RepositoryBrowser, File) which leads to calling the deprecated method hudson.model.User.get(String idOrFullName).
at hudson.model.User.get(User.java:573) at org.jenkinsci.plugins.p4.changes.P4ChangeEntry.setAuthor(P4ChangeEntry.java:234) local variable: org.jenkinsci.plugins.p4.changes.P4ChangeEntry#4608 at org.jenkinsci.plugins.p4.changes.P4ChangeParser$ChangeLogHandler.endElement(P4ChangeParser.java:250) local variable: org.jenkinsci.plugins.p4.changes.P4ChangeParser$ChangeLogHandler#14 at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:618) local variable: com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser#5 at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1728) local variable: com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl#4 local variable: com.sun.org.apache.xerces.internal.xni.QName#431 at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2899) local variable: com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDriver#4 at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542) local variable: com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl#4 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825) local variable: com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration#5 at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224) local variable: com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser#5 at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:637) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:326) at javax.xml.parsers.SAXParser.parse(SAXParser.java:330) at org.jenkinsci.plugins.p4.changes.P4ChangeParser.parse(P4ChangeParser.java:56)
Even though the changes returned by the perforce server are associated with usernames, the changesets are being serialized using the Jenkins User fullname/displayName as the changeuser in P4ChangeSet#store(File, List<P4ChangeEntry>). As a result when parsing the changelog the User must be resolved from its fullname which is the slowest scenario rather than by username/id which can be much quicker.
Similar to https://issues.jenkins.io/browse/JENKINS-72632