-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 2.346.2
Branch API Plugin 2.1046.v0
We have found a thread that is locked is this:
Computer.threadPoolForRemoting [#494987] / waiting for EC2 (DevSecOps Agent) - Linux (i-0b99db4829aeb5474) id=156631640" #13983096 daemon prio=5 os_prio=0 cpu=24150.51ms elapsed=8857.08s tid=0x00007f79d450c800 nid=0x2d447a in Object.wait() [0x00007f794d4b2000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.18/Native Method)
- waiting on <no object reference available>
at hudson.remoting.Request.call(Request.java:177)
- waiting to re-lock in wait() <0x00000007aee98d98> (a hudson.remoting.UserRequest)
at hudson.remoting.Channel.call(Channel.java:999)
at hudson.FilePath.act(FilePath.java:1194)
at hudson.FilePath.list(FilePath.java:2063)
at hudson.FilePath.listDirectories(FilePath.java:2037)
at jenkins.branch.WorkspaceLocatorImpl$Collector.onOnline(WorkspaceLocatorImpl.java:612)
- locked <0x000000060d199a70> (a java.lang.String)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:748)
We don't know for sure why EC2s agent doesn't like this:
waiting for EC2 (DevSecOps Agent)
but we do know it is fine on local storage, but not NFS.
Perhaps this could be refactored in order to deal with a large amount of directories on NFS?
[JENKINS-71717] plugin is too slow on NFS
Environment |
Original:
Jenkins 2.375.4
Branch API Plugin 2.1071.v1a_188a_562481 |
New:
Jenkins 2.346.2
Branch API Plugin 2.1071.v1a_188a_562481 |
Description |
Original:
Hello team,
We noticed that when we add option "Suppress automatic SCM triggering" with value "For matching branches suppress builds triggered by indexing (continue to honor webhooks), webhooks are OK (code 200) but the build is not automatic after a commit on a branch. !image-2023-04-25-09-51-09-101.png|width=462,height=174! On 2 multibranches pipelines, webhooks work when we suppress this option. I think we ave the last version of the plugin, how can we resolve this issue ? Is it a known problem ? Regards, Guillaume |
Environment |
Original:
Jenkins 2.346.2
Branch API Plugin 2.1071.v1a_188a_562481 |
New:
Jenkins 2.346.2
Branch API Plugin 2.1046.v0 |
Description |
New:
We have found a thread that is locked is this:
{color:#d1d2d3}Computer.threadPoolForRemoting [{color}{color:#d1d2d3}#494987{color}{color:#d1d2d3}] / waiting for EC2 (DevSecOps Agent) - Linux (i-0b99db4829aeb5474) id=156631640" #13983096 daemon prio=5 os_prio=0 cpu=24150.51ms elapsed=8857.08s tid=0x00007f79d450c800 nid=0x2d447a in Object.wait() [0x00007f794d4b2000]{color} {color:#d1d2d3} java.lang.Thread.State: TIMED_WAITING (on object monitor){color} {color:#d1d2d3} at java.lang.Object.wait([java.base@11.0.18|mailto:java.base@11.0.18]/Native Method){color} {color:#d1d2d3} - waiting on <no object reference available>{color} {color:#d1d2d3} at hudson.remoting.Request.call(Request.java:177){color} {color:#d1d2d3} - waiting to re-lock in wait() <0x00000007aee98d98> (a hudson.remoting.UserRequest){color} {color:#d1d2d3} at hudson.remoting.Channel.call(Channel.java:999){color} {color:#d1d2d3} at hudson.FilePath.act(FilePath.java:1194){color} {color:#d1d2d3} at hudson.FilePath.list(FilePath.java:2063){color} {color:#d1d2d3} at hudson.FilePath.listDirectories(FilePath.java:2037){color} {color:#d1d2d3} at jenkins.branch.WorkspaceLocatorImpl$Collector.onOnline(WorkspaceLocatorImpl.java:612){color} {color:#d1d2d3} - locked <0x000000060d199a70> (a java.lang.String){color} {color:#d1d2d3} at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:748){color} We don't know for sure why EC2s agent doesn't like this: {color:#d1d2d3}waiting for EC2 (DevSecOps Agent){color} but we do know it is fine on local storage, but not NFS. What is interesting is this: |
Attachment | New: image001.png [ 60892 ] |
Attachment | New: image002.png [ 60893 ] |
Description |
Original:
We have found a thread that is locked is this:
{color:#d1d2d3}Computer.threadPoolForRemoting [{color}{color:#d1d2d3}#494987{color}{color:#d1d2d3}] / waiting for EC2 (DevSecOps Agent) - Linux (i-0b99db4829aeb5474) id=156631640" #13983096 daemon prio=5 os_prio=0 cpu=24150.51ms elapsed=8857.08s tid=0x00007f79d450c800 nid=0x2d447a in Object.wait() [0x00007f794d4b2000]{color} {color:#d1d2d3} java.lang.Thread.State: TIMED_WAITING (on object monitor){color} {color:#d1d2d3} at java.lang.Object.wait([java.base@11.0.18|mailto:java.base@11.0.18]/Native Method){color} {color:#d1d2d3} - waiting on <no object reference available>{color} {color:#d1d2d3} at hudson.remoting.Request.call(Request.java:177){color} {color:#d1d2d3} - waiting to re-lock in wait() <0x00000007aee98d98> (a hudson.remoting.UserRequest){color} {color:#d1d2d3} at hudson.remoting.Channel.call(Channel.java:999){color} {color:#d1d2d3} at hudson.FilePath.act(FilePath.java:1194){color} {color:#d1d2d3} at hudson.FilePath.list(FilePath.java:2063){color} {color:#d1d2d3} at hudson.FilePath.listDirectories(FilePath.java:2037){color} {color:#d1d2d3} at jenkins.branch.WorkspaceLocatorImpl$Collector.onOnline(WorkspaceLocatorImpl.java:612){color} {color:#d1d2d3} - locked <0x000000060d199a70> (a java.lang.String){color} {color:#d1d2d3} at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:748){color} We don't know for sure why EC2s agent doesn't like this: {color:#d1d2d3}waiting for EC2 (DevSecOps Agent){color} but we do know it is fine on local storage, but not NFS. What is interesting is this: |
New:
We have found a thread that is locked is this:
{color:#d1d2d3}Computer.threadPoolForRemoting [{color}{color:#d1d2d3}#494987{color}{color:#d1d2d3}] / waiting for EC2 (DevSecOps Agent) - Linux (i-0b99db4829aeb5474) id=156631640" #13983096 daemon prio=5 os_prio=0 cpu=24150.51ms elapsed=8857.08s tid=0x00007f79d450c800 nid=0x2d447a in Object.wait() [0x00007f794d4b2000]{color} {color:#d1d2d3} java.lang.Thread.State: TIMED_WAITING (on object monitor){color} {color:#d1d2d3} at java.lang.Object.wait([java.base@11.0.18|mailto:java.base@11.0.18]/Native Method){color} {color:#d1d2d3} - waiting on <no object reference available>{color} {color:#d1d2d3} at hudson.remoting.Request.call(Request.java:177){color} {color:#d1d2d3} - waiting to re-lock in wait() <0x00000007aee98d98> (a hudson.remoting.UserRequest){color} {color:#d1d2d3} at hudson.remoting.Channel.call(Channel.java:999){color} {color:#d1d2d3} at hudson.FilePath.act(FilePath.java:1194){color} {color:#d1d2d3} at hudson.FilePath.list(FilePath.java:2063){color} {color:#d1d2d3} at hudson.FilePath.listDirectories(FilePath.java:2037){color} {color:#d1d2d3} at jenkins.branch.WorkspaceLocatorImpl$Collector.onOnline(WorkspaceLocatorImpl.java:612){color} {color:#d1d2d3} - locked <0x000000060d199a70> (a java.lang.String){color} {color:#d1d2d3} at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:748){color} We don't know for sure why EC2s agent doesn't like this: {color:#d1d2d3}waiting for EC2 (DevSecOps Agent){color} but we do know it is fine on local storage, but not NFS. What is interesting is this: !image001.png|thumbnail! Perhaps this could be refactored in order to deal with a large amount of directories on NFS? |