Skip to content

[JENKINS-61475] Infinite loop in StandardGraphLookupView #502

@jenkins-infra-bot

Description

@jenkins-infra-bot

About once a week, multiple threads handling HTTP requests matching the patterns /blue/rest/organizations/jenkins/pipelines//pipelines//runs// or /blue/organizations/jenkins/%2F/detail///pipeline/ will get stuck in an infinite loop in StandardGraphLookupView.bruteForceScanForEnd.

Each thread that get stuck ties a CPU core, and they tend to happen in batches of about 20-30 threads. This results in the Jenkins web UI appearing to be very slow to users. The resolution so far has been to use the JavaMelody monitoring plugin to kill the stuck threads one by one.

I've attached stack traces from two example threads showing that they get stuck in the same place, as well as a snapshot of the CPU usage at the time. There was nothing supicious going on at the time, and I've been unable to manually reproduce the issue.

I believe something like https://github.com/francoiscampbell/workflow-api-plugin/compare/master...graph-lookup-concurrent should address the issue, but I'm not sure how to verify that.


Originally reported by fcampbell, imported from: Infinite loop in StandardGraphLookupView
  • status: Open
  • priority: Minor
  • component(s): workflow-api-plugin
  • label(s): pipeline
  • resolution: Unresolved
  • votes: 1
  • watchers: 2
  • imported: 20260601-173816
Raw content of original issue

About once a week, multiple threads handling HTTP requests matching the patterns /blue/rest/organizations/jenkins/pipelines/<folder>/pipelines/<job>/runs/<number>/ or /blue/organizations/jenkins/<folder>%2F<job>/detail/<job>/<number>/pipeline/ will get stuck in an infinite loop in StandardGraphLookupView.bruteForceScanForEnd.

Each thread that get stuck ties a CPU core, and they tend to happen in batches of about 20-30 threads. This results in the Jenkins web UI appearing to be very slow to users. The resolution so far has been to use the JavaMelody monitoring plugin to kill the stuck threads one by one.

I've attached stack traces from two example threads showing that they get stuck in the same place, as well as a snapshot of the CPU usage at the time. There was nothing supicious going on at the time, and I've been unable to manually reproduce the issue.

I believe something like https://github.com/francoiscampbell/workflow-api-plugin/compare/master...graph-lookup-concurrent should address the issue, but I'm not sure how to verify that.

environment
OS: Amazon Linux 2<br/>
Jenkins version: 2.223<br/>
Java version: 8.212.04-r0<br/>
JAVA_OPTS: &quot;-Djava.awt.headless=true -XX:ActiveProcessorCount=48 -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85&quot;<br/>
Installed plugins: in comment<br/>
How Jenkins is accessed: Through an AWS Classic Load Balancer<br/>
Jenkins installation method: Docker image jenkins/jenkins:2.223-alpine running on ECS, agents launched on-demand by ECS Plugin and connecting via JNLP<br/>
Web browser: Various users affected, all using modern versions of Chrome/Firefox<br/>
4 attachments

Metadata

Metadata

Assignees

No one assigned

    Type

    No fields configured for Bug.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions