[JENKINS-75263] Don't serialize user displayname as change entry changeuser

Type: Bug
Resolution: Unresolved
Priority: Major
Component/s: p4-plugin
Labels:
None
Environment:
Jenkins Version 2.462.1
P4 Plugin Version1.16.0
P4 Server version: P4D/LINUX26X86_64/2023.1/2576871 (2024/03/25)

Similar Issues:
Powered by SuggestiMate

Show

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.

- - Sort By Name
  - Sort By Date
  - Ascending
  - Descending
  - Thumbnails
  - List
  - Download All

stacktrace.txt
8 kB
2025-02-12 06:39

Stuart Rowe created issue - 2025-02-12 06:46

Stuart Rowe made changes - 2025-02-12 06:49

Summary

Original: Attempt to find User by Id rather before fallback to by FullName

New: Attempt to find User by Id before fallback to by FullName

Stuart Rowe made changes - 2025-02-12 06:49

Description

Original: Recently pipelines on our Jenkins controllers have been getting stuck while processing p4 change set.

A heap dump shows the threads for the impacted jobs waiting deep within a stack trace starting from a call to the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

Because the changelist summary returned from the p4 server uses the full name of the user as the change username, the call to {{User.get}} ultimately has to resolve a user Id from the fullname. There seems to be deadlock while trying to complete the user resolution as many threads are stuck waiting under the same code path.

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

New: 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 the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

Because the changelist summary returned from the p4 server uses the full name of the user as the change username, the call to {{User.get}} ultimately has to resolve a user Id from the fullname. There seems to be deadlock while trying to complete the user resolution as many threads are stuck waiting under the same code path.

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

Stuart Rowe made changes - 2025-02-13 06:46

Summary

Original: Attempt to find User by Id before fallback to by FullName

New: Don't serialize user displayname as change entry changeuser

Stuart Rowe made changes - 2025-02-13 06:47

Description

Original: 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 the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

Because the changelist summary returned from the p4 server uses the full name of the user as the change username, the call to {{User.get}} ultimately has to resolve a user Id from the fullname. There seems to be deadlock while trying to complete the user resolution as many threads are stuck waiting under the same code path.

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

New: 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 the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

Stuart Rowe made changes - 2025-02-13 06:48

Description

Original: 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 the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

New: 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 the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

{noformat}
    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)
{noformat}

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

Stuart Rowe made changes - 2025-02-13 06:57

Description

Original: 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 the deprecated variant of [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].

{noformat}
    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)
{noformat}

The lookup by fullname doesn't seem necessary for exisitng users when the p4 login name can be used as the id when calling [hudson.model.User.getById(String id, boolean create)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L668]. This may not cover the situation of all users but it should be an improvement for some.

New: 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)|https://github.com/jenkinsci/p4-plugin/blob/d10735c1b27b84960e5927bd604bf14d1285273f/src/main/java/org/jenkinsci/plugins/p4/changes/P4ChangeParser.java#L47] which leads to calling the deprecated method [hudson.model.User.get(String idOrFullName)|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L598].
{noformat}
    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)
{noformat}
Even though the changes returned by the perforce server are associated with usernames, the changesets are being serialized using the Jenkins [User fullname/displayName|https://github.com/jenkinsci/jenkins/blob/9474c89bf1796a205e1ffa96fbeddd3ae8e5a2c0/core/src/main/java/hudson/model/User.java#L176] as the changeuser in [P4ChangeSet#store(File, List<P4ChangeEntry>)|https://github.com/jenkinsci/p4-plugin/blob/d10735c1b27b84960e5927bd604bf14d1285273f/src/main/java/org/jenkinsci/plugins/p4/changes/P4ChangeSet.java#L70]. 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.

Stuart Rowe made changes - 2025-02-13 07:54

Status

Original: Open [ 1 ]

New: In Progress [ 3 ]

Stuart Rowe made changes - 2025-02-13 07:54

Status

Original: In Progress [ 3 ]

New: In Review [ 10005 ]

Assignee:: Unassigned

Reporter:: Stuart Rowe

Votes:: 0 Vote for this issue

Watchers:: 1 Start watching this issue

Created:: 2025-02-12 06:46

Updated:: 2025-02-13 07:54

Jenkins

Details

Description

Attachments

Attachments

Activity

People

Dates