[JIRA] (JENKINS-42013) Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Title: Message Title
Baptiste Mathus commented on JENKINS-42013
Re: Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
After a quick checkwe re-read https://github.com/jenkinsci/jenkins/blob/f0c5108184a75e589493afe6d54879b5c4b7ed54/core/src/main/java/hudson/node_monitors/NodeMonitor.java#L94-L106 and (thanks rsandell) stopping/handling previous requests is said to be already handled. So, if requests are piling up, there is a bug in the code. IOW, we may not need to add a "timeout" feature on NodeMonitor, but instead just fix the problem that makes the cancellation not work (if this proves to actually be the problem).
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.178881.1487072168000.515.1581935280232%40Atlassian.JIRA.
[JIRA] (JENKINS-42013) Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Title: Message Title
Alvaro Lobato updated an issue
Jenkins / JENKINS-42013
Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Change By:
Alvaro Lobato
Attachment:
traceback (1).txt
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42013) Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Title: Message Title
Alvaro Lobato updated an issue
Jenkins / JENKINS-42013
Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Change By:
Alvaro Lobato
If there is a blocked remote channel to an agent the /threadDump page won't be generated as it will block trying to get the threadDump from that agent.See attached stacktrace with an example.We should add a timeout to each remote operation we perform on the threadDump page or start printing the local results right away, so if a remote thread dump fails we still have the local one.This happened on 2.32Steps to reproduce:1. Somehow hang a remoting channel. In this case also was the backup plugin transferring data + maybe a connectivity issue.2. Wait some some time for the monitoring threads to launch again, the monitoring threads will be locked on the channel and they will should begin to multiply in a period equal to the check time
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-42013) Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Title: Message Title
Alvaro Lobato created an issue
Jenkins / JENKINS-42013
Multiple monitoring thread ("Free Disk Space", "Free Temp Space", etc) can be running at the same time if the pervious execution didn't end before the next one.
Issue Type:
Bug
Assignee:
Unassigned
Components:
core
Created:
2017/Feb/14 11:36 AM
Priority:
Minor
Reporter:
Alvaro Lobato
If there is a blocked remote channel to an agent the /threadDump page won't be generated as it will block trying to get the threadDump from that agent. See attached stacktrace with an example. We should add a timeout to each remote operation we perform on the threadDump page or start printing the local results right away, so if a remote thread dump fails we still have the local one. This happened on 2.32 Steps to reproduce: 1. Somehow hang a remoting channel. In this case also was the backup plugin transferring data + maybe a connectivity issue. 2. Wait some some time for the monitoring threads to launch again, the monitoring threads will be locked on the channel and they will begin to multiply in a period equal to the check time
Add Comment
