-
Bug
-
Resolution: Unresolved
-
Critical
-
None
This is to track the problem originally reported here: http://n4.nabble.com/Polling-hung-td1310838.html#a1310838
The referenced thread is relocated to http://jenkins.361315.n4.nabble.com/Polling-hung-td1310838.html
What the problem boils down to is that many remote operations are performed synchronously causing the channel object to be locked while a response returns. In situations where a lengthy remote operations is using the channel, SCM polling can be blocked waiting for the monitor on the channel to be released. In extreme situations, all the polling threads can wind up waiting on object monitors for the channel objects, preventing further processing of polling tasks.
Furthermore, if the slave dies, the locked channel object still exists in the master JVM. If no IOException is thrown to indicate the termination of the connection to the pipe, the channel can never be closed because Channel.close() itself is a sychronized operation.
- is related to
-
-
- Resolved
-
-
-
- Closed
-
-
JENKINS-19055 In case of connection loss, slave JVM should restart itself if it can
-
- Resolved
-
- links to
[JENKINS-5413] SCM polling getting hung
Dean Yu
created issue -
mdillon
made changes -
| Attachment | New: threads.vetted.txt [ 19185 ] |
lkishalmi
made changes -
| Component/s | New: master-slave [ 15489 ] | |
| Component/s | Original: subversion [ 15485 ] | |
| Summary | Original: SVN polling on slaves getting hung | New: SCM polling on slaves getting hung |
jpshackelford
made changes -
| Attachment | New: thread_dump_02.txt [ 19535 ] | |
| Attachment | New: hung_scm_pollers_02.PNG [ 19536 ] |
lkishalmi
made changes -
| Link |
New:
This issue is related to |
| Description |
Original:
This is to track the problem originally reported here: http://n4.nabble.com/Polling-hung-td1310838.html#a1310838 What the problem boils down to is that many remote operations are performed synchronously causing the channel object to be locked while a response returns. In situations where a lengthy remote operations is using the channel, SCM polling can be blocked waiting for the monitor on the channel to be released. In extreme situations, all the polling threads can wind up waiting on object monitors for the channel objects, preventing further processing of polling tasks. Furthermore, if the slave dies, the locked channel object still exists in the master JVM. If no IOException is thrown to indicate the termination of the connection to the pipe, the channel can never be closed because Channel.close() itself is a sychronized operation. |
New:
This is to track the problem originally reported here: http://n4.nabble.com/Polling-hung-td1310838.html#a1310838 The referenced thread is relocated to http://jenkins.361315.n4.nabble.com/Polling-hung-td1310838.html What the problem boils down to is that many remote operations are performed synchronously causing the channel object to be locked while a response returns. In situations where a lengthy remote operations is using the channel, SCM polling can be blocked waiting for the monitor on the channel to be released. In extreme situations, all the polling threads can wind up waiting on object monitors for the channel objects, preventing further processing of polling tasks. Furthermore, if the slave dies, the locked channel object still exists in the master JVM. If no IOException is thrown to indicate the termination of the connection to the pipe, the channel can never be closed because Channel.close() itself is a sychronized operation. |
| Assignee | New: Jes Struck [ jstruck ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Status | Original: In Progress [ 3 ] | New: Open [ 1 ] |
| Assignee | Original: Jes Struck [ jstruck ] |
Markus
made changes -
| Link |
New:
This issue is related to |