[JIRA] (JENKINS-15803) git polling mechanism can have build in infinite loop
Kristia Rosenvold commented on JENKINS-15803 git polling mechanism can have build in infinite loop Temporarily change base class of GitException to a checked exception and it all becomes clear. Sorry about the line numbers. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15803) git polling mechanism can have build in infinite loop
Kristia Rosenvold edited a comment on JENKINS-15803 git polling mechanism can have build in infinite loop Temporarily change base class of GitException to a checked exception and it all becomes clear. Sorry about the line numbers, I was a few versions behind when I made the patch/issue This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15803) git polling mechanism can have build in infinite loop
Kristia Rosenvold created JENKINS-15803 git polling mechanism can have build in infinite loop Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: git Created: 12/Nov/12 11:51 AM Description: We have a problem on the ASF git integration that causes change detection logic to always trigger changes, subsequently running the builds non-stop. I am quiet sure I have tracked this and will explain it here: jenkins-core: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1404 Look at the catch-block surrounding the call to "poll". https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L678 https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L741 Both of these method calls can produce a "GitException" which is of type RunTimeException. When they hit the "catch" in AbstractProject#poll, they will enter the RuntimeException block. The root cause seems to be that GitAPI status code detection (GitAPI java line 824) does not distinguish between "IOException" and other kinds of exception. Given that we are unable to distinguish, it probably makes more sense to make the "poll" method wrap any git exception in an IOException, but the optimal would be to determine what status codes git uses for network related failures and throw ioexceptions in those cases. Project: Jenkins Priority: Major Reporter: Kristia Rosenvold This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15803) git polling mechanism can have build in infinite loop
Kristia Rosenvold edited a comment on JENKINS-15803 git polling mechanism can have build in infinite loop https://github.com/jenkinsci/git-plugin/pull/110 wraps any GitException in an IOException. Given that it is "impossible" to reliably separate real IOExceptions from configuration/corruption exceptions, this seems like the least evil of the two possible solutions. It should avoid runaway builds and the subsequent email spamming from jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15803) git polling mechanism can have build in infinite loop
Kristia Rosenvold commented on JENKINS-15803 git polling mechanism can have build in infinite loop https://github.com/jenkinsci/git-plugin/pull/110 wraps any GitException in a runtime exception. Given that it is "impossible" to reliably separate real IOExceptions from configuration/corruption exceptions, this seems like the least evil of the two possible solutions. It should avoid runaway builds and the subsequent email spamming from jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13395) Still having java.io.StreamCorruptedException with 1.458
Kristia Rosenvold commented on JENKINS-13395 Still having java.io.StreamCorruptedException with 1.458 I closed the pull request because it was obviously not going to work that way. I re-read our discussion on the pull request and I think I understand that you're fine with externalizing the "start" method from the construction logic ? All clients would still have to be updated to call "start" (or we could shudder do it lazily), since there is to my best knowledge no safe way to start a thread referencing "this" in a constructor. I can rework the patch once you confirm you think this is ok This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13395) Still having java.io.StreamCorruptedException with 1.458
Kristia Rosenvold commented on JENKINS-13395 Still having java.io.StreamCorruptedException with 1.458 There is a constructor escape of Channel.this into SynchronousCommandTransport.ReaderThread through transport.setup (line 428 in Channel) The solution is probably to extract a static factory method for Channel constructor and do transport.setup in the factory method. I have reviewed the code for thread safety and this is the only thing I've found so far. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
