[JIRA] (JENKINS-37771) "Run the build in a RVM-managed environment" field gets unchecked after restarting the Jenkins server.
Title: Message Title Jonathan Strickland edited a comment on JENKINS-37771 Re: "Run the build in a RVM-managed environment" field gets unchecked after restarting the Jenkins server. Wish my team had read this thread before we did an upgrade. We found 1 current workaround is to "reload configuration" after the reboot. For some reason, this will enables the build environment configuration. As noted above, downgrade from 0.13 -> 0.12 fixes the issue. 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-37771) "Run the build in a RVM-managed environment" field gets unchecked after restarting the Jenkins server.
Title: Message Title Jonathan Strickland commented on JENKINS-37771 Re: "Run the build in a RVM-managed environment" field gets unchecked after restarting the Jenkins server. Wish my team had read this thread before we did an upgrade. We found 1 current workaround is to "reload configuration" after the reboot. For some reason, this will enables the build environment configuration. 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-38603) Coverity Plugin 1.8.0 fails on cov-analyze - intermediate directory contains no translation units
Title: Message Title Jonathan Strickland commented on JENKINS-38603 Re: Coverity Plugin 1.8.0 fails on cov-analyze - intermediate directory contains no translation units Thanks, we will try this in our next go round of staging upgrades. We have multiple Coverity jobs (hosting 10+ projects on our server) thus we would have to plan for this to upgrade and reconfigure the appropriate jobs. 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-38603) Coverity Plugin 1.8.0 fails on cov-analyze - intermediate directory contains no translation units
Title: Message Title Jonathan Strickland created an issue Jenkins / JENKINS-38603 Coverity Plugin 1.8.0 fails on cov-analyze - intermediate directory contains no translation units Issue Type: Bug Assignee: Ken Dang Components: coverity-plugin Created: 2016/Sep/29 12:41 PM Environment: Jenkins Core - 1.656 Coverity Plugin - 1.8.0 Slave node (Centos 7) runs all builds (No builds on master) Priority: Critical Reporter: Jonathan Strickland [pr-static-analysis] $ /opt/cisco/trust/coverity-analysis/bin/cov-analyze --dir /home/lab1/workspace/pr-static-analysis/coverity -all --enable-constraint-fpp --paths 5000 Coverity Static Analysis version 8.1.0 on Linux 3.10.0-327.18.2.el7.x86_64 x86_64 Internal version numbers: 5511032c07 p-jasper1-push-24789.298.98 Using 10 workers as limited by CPU(s) Looking for translation units Error: intermediate directory contains no translation units. [Coverity] /opt/cisco/trust/coverity-analysis/bin/cov-analyze returned 2, aborting... Build step 'Coverity' changed build result to FAILURE Finished: FAILURE This code works with 1.7.1. We started investigating a bit and found a change which I was evaluating to possibly causing the issues. In 1.7.1, https://github.com/jenkinsci/coverity-plugin/blob/coverity-1.7.1/src/main/java/jenkins/plugins/coverity/CoverityLauncherDecorator.java#L227, and this works. In 1.8.0, https://github.com/jenkinsci/coverity-plugin/blob/be3051fbc6f5960917d05db7e40030396565bc37/src/main/java/jenkins/plugins/coverity/CoverityLauncherDecorator.java#L225 .. We are not sure exactly what if
[JIRA] (JENKINS-38515) Get the output from git client for debugging
Title: Message Title Jonathan Strickland closed an issue as Not A Defect See last comment; you have to hit an error condition to see the full logs which is thrown up in the GitException. A good path will not show the logs. Jenkins / JENKINS-38515 Get the output from git client for debugging Change By: Jonathan Strickland Status: Open Closed Resolution: Not A Defect 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
[JIRA] (JENKINS-38515) Get the output from git client for debugging
Title: Message Title Jonathan Strickland commented on JENKINS-38515 Re: Get the output from git client for debugging Mark Waite Ok so I feel like I wasted a lot of resources time on this; definitely apologize in advance. After looking at the code (https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L1752) I found that its only going to give the stderr and stdout output if an actual error occurs. Thus, my testing of good path we were not seeing the full dumps. After testing with an error condition (simulate bad credentials which is really easy) we saw the complete curl dumps. In case someone else hits this issue and needs debug tracing, this is what we did: 1. Inject the following into your environment. We did it using puppet to orchestrate our environments and place a profile.d file on build servers / container images: $ more /etc/profile.d/git.sh export GIT_CURL_VERBOSE=1 export GIT_TRACE=1 umask 077 These may/may not work with 2.x git, it appears some of the trace/verbose env vars have changed. 2. You have to hit an error conditions for them to show up. https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L1752 as an error (timeout, bad status code, ect..) will throw a git exception with the debug information from stderr / stdout of the git cli command. 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,
[JIRA] (JENKINS-38515) Get the output from git client for debugging
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-38515 Get the output from git client for debugging Change By: Jonathan Strickland We have been experiencing some infrastructure issues are causing some of our git commands to fail (fetch, pull, ect..) on our Jenkins infrastructure side. We wanted to turn on some deeper git trace levels to capture further information to help us debug the issues. On our jenkins slaves/master we turned on the below to enable git trace. The trace shows up when running via the command line and the env vars show up in the system configuration for each slave/master.[jenkins@15d08c2a101e ~]$ more /etc/profile.d/git.shexport GIT_CURL_VERBOSE=1export GIT_TRACE=1The issue we are having is enabling the correct global/job environment variables to show this output in the console of the jobs. We attempted to enable the verbose env var at https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/GitClient.java (see attachement) but do not get much more information. Is there an easy way to get the git command output sent to the job console . ? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38515) Get the output from git client for debugging
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-38515 Get the output from git client for debugging Change By: Jonathan Strickland Summary: Get the output from git client for debugging 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-38515) Get the output from
Title: Message Title Jonathan Strickland created an issue Jenkins / JENKINS-38515 Get the output from Issue Type: Bug Assignee: Mark Waite Attachments: jenkins_gitclient_verbose_script_console.jpg Components: git-client-plugin Created: 2016/Sep/26 5:24 PM Environment: Centos 7.x [jenkins@15d08c2a101e ~]$ git --version trace: built-in: git 'version' git version 1.8.3.1 Git Client Plugin - 2.0.0 Git Plugin - 3.0.0 Jenkins Core - 1.656 Priority: Minor Reporter: Jonathan Strickland We have been experiencing some infrastructure issues are causing some of our git commands to fail (fetch, pull, ect..) on our Jenkins infrastructure side. We wanted to turn on some deeper git trace levels to capture further information to help us debug the issues. On our jenkins slaves/master we turned on the below to enable git trace. The trace shows up when running via the command line and the env vars show up in the system configuration for each slave/master. [jenkins@15d08c2a101e ~]$ more /etc/profile.d/git.sh export GIT_CURL_VERBOSE=1 export GIT_TRACE=1 The issue we are having is enabling the correct global/job environment variables to show this output in the console of the jobs. We attempted to enable the verbose env var at https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/GitClient.java (see attachement) but do not get much more information. Is there an easy way to get the git command output sent to the job console.
[JIRA] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland commented on JENKINS-30558 Re: Cron based jobs are no longer triggered kang hao Kang, I would recommend opening up a new issue with your problem. If the upgrade of the Stash Trigger Plugin is causing issues, please note this in the new issue (to and from version) Regards, Jonathan 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-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland resolved as Fixed Resolved with Merge pull request #9 from jwstric2/JENKINS-30558. Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Status: Open Resolved Resolution: Fixed 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
[JIRA] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland assigned an issue to Jonathan Strickland Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Assignee: Jonathan Strickland 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] [external-resource-dispatcher-plugin] (JENKINS-32917) Locked resource in use by multiple jobs
Title: Message Title Jonathan Strickland edited a comment on JENKINS-32917 Re: Locked resource in use by multiple jobs Running Core Jenkins 1.651Externeral Dispatcher: 1.1.0 Just started hitting this issue just recently as we are expanding our pipelines and resources. From reviewing the code (very briefly), I don't see anywhere that would prevent multiple threads obtaining the resource lock at the same time. Following the code from https://github.com/jenkinsci/external-resource-dispatcher-plugin/blob/master/src/main/java/com/sonyericsson/jenkins/plugins/externalresource/dispatcher/ExternalResourceQueueTaskDispatcher.java#L113 to https://github.com/jenkinsci/external-resource-dispatcher-plugin/blob/master/src/main/java/com/sonyericsson/jenkins/plugins/externalresource/dispatcher/utils/resourcemanagers/ResourceMonitorExternalResourceManager.java#L203 there appear to be multiple places that could have mutual exclusion problems. Perhaps the job dispatcher in Jenkins runs in a single thread; but I would have to review the architecture to be certain and from what is being observed this may not be the case.The really unfortunate part of this and any mutual exclusion problem is I turned on full logging to observe the behavior and it went away. I'm going to fork this off and see if we can propose a possible fix. Unless, the Queue handler in Jenkins is itself running in a single thread. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [external-resource-dispatcher-plugin] (JENKINS-32917) Locked resource in use by multiple jobs
Title: Message Title Jonathan Strickland commented on JENKINS-32917 Re: Locked resource in use by multiple jobs Just started hitting this issue just recently as we are expanding our pipelines and resources. From reviewing the code (very briefly), I don't see anywhere that would prevent multiple threads obtaining the resource lock at the same time. Following the code from https://github.com/jenkinsci/external-resource-dispatcher-plugin/blob/master/src/main/java/com/sonyericsson/jenkins/plugins/externalresource/dispatcher/ExternalResourceQueueTaskDispatcher.java#L113 to https://github.com/jenkinsci/external-resource-dispatcher-plugin/blob/master/src/main/java/com/sonyericsson/jenkins/plugins/externalresource/dispatcher/utils/resourcemanagers/ResourceMonitorExternalResourceManager.java#L203 there appear to be multiple places that could have mutual exclusion problems. Perhaps the job dispatcher in Jenkins runs in a single thread; but I would have to review the architecture to be certain and from what is being observed this may not be the case. The really unfortunate part of this and any mutual exclusion problem is I turned on full logging to observe the behavior and it went away. I'm going to fork this off and see if we can propose a possible fix. Unless, the Queue handler in Jenkins is itself running in a single thread. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [jobconfighistory-plugin] (JENKINS-34861) Job Config History Plugin failing when comparing diff between config files
Title: Message Title Jonathan Strickland commented on JENKINS-34861 Re: Job Config History Plugin failing when comparing diff between config files Jochen A. Fürbacher Thanks for the update. Let me schedule an upgrade with my team; this was the first issue found with my search engine. After reading JENKINS 33289, it looks like the same. I'm ok with closure of this issue if Stefan Brausch is ok with it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [jobconfighistory-plugin] (JENKINS-34861) Job Config History Plugin failing when comparing diff between config files
Title: Message Title Jonathan Strickland edited a comment on JENKINS-34861 Re: Job Config History Plugin failing when comparing diff between config files Same here with following:Job Config History: 2.12Jenkins Core: 1.651The error is producible on multiple job styles, free style, multijob, folder, ect... I attached the full version + plugins of our server. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [jobconfighistory-plugin] (JENKINS-34861) Job Config History Plugin failing when comparing diff between config files
Title: Message Title Jonathan Strickland commented on JENKINS-34861 Re: Job Config History Plugin failing when comparing diff between config files Same here with following: Job Config History: 2.12 Jenkins Core: 1.651 The error is producible on multiple job styles, free style, multijob, folder, ect... Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [jobconfighistory-plugin] (JENKINS-34861) Job Config History Plugin failing when comparing diff between config files
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-34861 Job Config History Plugin failing when comparing diff between config files Change By: Jonathan Strickland Attachment: support_2016-05-17_13.36.16.zip Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-25704) Scheduled triggering stops working until restart
Title: Message Title Jonathan Strickland commented on JENKINS-25704 Re: Scheduled triggering stops working until restart Tom Lachner See in your thread dump if you see that of a thread dump at JENKINS-30588 java.net.SocketInputStream.socketRead0 followed in stack is the stashpullrequest timer Its misleading but yes the cron thread is may be waiting on completion of the timer task of the stash pull request, which will never complete due to a hung socket. David Resnick, we actually didn't see the issue until multiple teams in our group starting having multiple repos each with pull requests (thus multiple jobs with more load on our production stash instance) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-25704) Scheduled triggering stops working until restart
Title: Message Title Jonathan Strickland edited a comment on JENKINS-25704 Re: Scheduled triggering stops working until restart [~timguy] See in your thread dump if you see that of a thread dump at JENKINS-30588java.net.SocketInputStream.socketRead0followed in stack is the stashpullrequest timerIts misleading but yes the cron thread is may be waiting on completion of the timer task of the stash pull request, which will never complete due to a hung socket. [~david_resnick], we actually didn't see the issue until multiple teams in our group starting having multiple repos each with pull requests (thus multiple jobs with more load on our production stash instance) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [stash-pullrequest-builder-plugin] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland commented on JENKINS-30558 Re: Cron based jobs are no longer triggered james norman The Stash Pull Requester plugin was a great initial choice for us to get started. Check out https://marketplace.atlassian.com/plugins/se.bjurr.prnfs.pull-request-notifier-for-stash/server/overview for the push model; this has been serving us well for over a month now (less load on Jenkins and the stash server too). https://christiangalsterer.wordpress.com/2015/04/23/continuous-integration-for-pull-requests-with-jenkins-and-stash/ gives a good walk-through. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [stash-pullrequest-builder-plugin] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland commented on JENKINS-30558 Re: Cron based jobs are no longer triggered james norman, sorry for the late reply. See https://github.com/jenkinsci/stash-pullrequest-builder-plugin/pull/9. I fixed merge conflicts 3 times due to other commit breakages actively happening but the administrator of the plugin has yet to accept the fix. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [coverity-plugin] (JENKINS-30886) BUG: Could not find Coverity Analysis home directory
Title: Message Title Jonathan Strickland commented on JENKINS-30886 Re: BUG: Could not find Coverity Analysis home directory Coverity Plugin Version: 1.6.0 we hit issue. Rolled back to 1.5.2 and service restored. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [stash-pullrequest-builder-plugin] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Component/s: stash-pullrequest-builder-plugin Component/s: core Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [stash-pullrequest-builder-plugin] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Priority: Critical Major Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [stash-pullrequest-builder-plugin] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland commented on JENKINS-30558 Re: Cron based jobs are no longer triggered I still haven’t gotten into the heart of the Jenkins Core code but apparently 1 bad plug-in, as pretty obvious the below debugs, can have a detrimental impact on the system if it hangs within its own timer task code. Using jstack on the Jenkins process; I found the hang happens deep at native socket code causing the Stash Trigger to never complete. Thread dump looks like this: Thread 23311: (state = IN_NATIVE) java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise) java.net.SocketInputStream.read(byte[], int, int, int) @bci=87, line=152 (Compiled frame) java.net.SocketInputStream.read(byte[], int, int) @bci=11, line=122 (Compiled frame) sun.security.ssl.InputRecord.readFully(java.io.InputStream, byte[], int, int) @bci=21, line=442 (Compiled frame) sun.security.ssl.InputRecord.read(java.io.InputStream, java.io.OutputStream) @bci=32, line=480 (Compiled frame) sun.security.ssl.SSLSocketImpl.readRecord(sun.security.ssl.InputRecord, boolean) @bci=44, line=934 (Compiled frame) sun.security.ssl.SSLSocketImpl.readDataRecord(sun.security.ssl.InputRecord) @bci=15, line=891 (Compiled frame) sun.security.ssl.AppInputStream.read(byte[], int, int) @bci=72, line=102 (Compiled frame) java.io.BufferedInputStream.fill() @bci=175, line=235 (Interpreted frame) java.io.BufferedInputStream.read() @bci=12, line=254 (Compiled frame) org.apache.commons.httpclient.HttpParser.readRawLine(java.io.InputStream) @bci=19, line=78 (Compiled frame) org.apache.commons.httpclient.HttpParser.readLine(java.io.InputStream, java.lang.String) @bci=11, line=106 (Interpreted frame) org.apache.commons.httpclient.HttpConnection.readLine(java.lang.String) @bci=19, line=1116 (Interpreted frame)
[JIRA] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland commented on JENKINS-30558 Re: Cron based jobs are no longer triggered The issue may possibly be a result of stashbuilder after looking at the jstack trace on the master. I attached 2 jstack traces 5 minutes apart, see thread 23311. Its sitting at java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int). I'm not very familiar with the Timer code; but was wondering if this single job's socket not completelying in the timertask could cause impact to the whole system. Thread 23311: (state = IN_NATIVE) java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise) java.net.SocketInputStream.read(byte[], int, int, int) @bci=87, line=152 (Compiled frame) java.net.SocketInputStream.read(byte[], int, int) @bci=11, line=122 (Compiled frame) sun.security.ssl.InputRecord.readFully(java.io.InputStream, byte[], int, int) @bci=21, line=442 (Compiled frame) sun.security.ssl.InputRecord.read(java.io.InputStream, java.io.OutputStream) @bci=32, line=480 (Compiled frame) sun.security.ssl.SSLSocketImpl.readRecord(sun.security.ssl.InputRecord, boolean) @bci=44, line=934 (Compiled frame) sun.security.ssl.SSLSocketImpl.readDataRecord(sun.security.ssl.InputRecord) @bci=15, line=891 (Compiled frame) sun.security.ssl.AppInputStream.read(byte[], int, int) @bci=72, line=102 (Compiled frame) java.io.BufferedInputStream.fill() @bci=175, line=235 (Interpreted frame) java.io.BufferedInputStream.read() @bci=12, line=254 (Compiled frame) org.apache.commons.httpclient.HttpParser.readRawLine(java.io.InputStream) @bci=19, line=78 (Compiled frame) org.apache.commons.httpclient.HttpParser.readLine(java.io.InputStream, java.lang.String) @bci=11, line=106 (Interpreted frame) org.apache.commons.httpclient.HttpConnection.readLine(java.lang.String)
[JIRA] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Attachment: jenkins_threaddump_2.txt Attachment: jenkins_threaddump_1.txt Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Hit the issue on 10/8/2015 too. 3:39:00 PM was the last log that was logged by the logger. This correlates with all the polling jobs no longer being scheduled. Only interesting item I found in the jenkins log was an exception at 3:37:00 WARNING: java.nio.channels.ClosedChannelException at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:270) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:479) at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:293) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:402) at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:337) at org.eclipse.jetty.io.nio.SslConnection.access$900(SslConnection.java:48) at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.flush(SslConnection.java:738) at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.shutdownOutput(SslConnection.java:641) at org.eclipse.jetty.io.nio.SslConnection.onIdleExpired(SslConnection.java:260) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.onIdleExpired(SelectChannelEndPoint.java:349) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:326) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Oct 08, 2015 3:38:00 PM stashpullrequestbuilder.stashpullrequestbuilder.StashPullRequestsBuilder run Change By: Jonathan Strickland Attachment: triggers_fine_log_10_8_2015.txt Add Comment
[JIRA] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland edited a comment on JENKINS-30558 Re: Cron based jobs are no longer triggered Hit the issue on 10/8/2015 too. 3:39:00 PM was the last log that was logged by the logger. This correlates with all the polling jobs no longer being scheduled.Only interesting item I found in the jenkins log was an exception at 3:37:00 Oct 08, 2015 3:37:13 PM org.eclipse.jetty.util.log.JavaUtilLog warn WARNING:java.nio.channels.ClosedChannelExceptionat sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:270)at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:479)at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:293)at org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:402)at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:337)at org.eclipse.jetty.io.nio.SslConnection.access$900(SslConnection.java:48)at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.flush(SslConnection.java:738)at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.shutdownOutput(SslConnection.java:641)at org.eclipse.jetty.io.nio.SslConnection.onIdleExpired(SslConnection.java:260)at org.eclipse.jetty.io.nio.SelectChannelEndPoint.onIdleExpired(SelectChannelEndPoint.java:349)at org.eclipse.jetty.io.nio.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:326)at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)at java.lang.Thread.run(Thread.java:745)Oct 08, 2015 3:38:00 PM stashpullrequestbuilder.stashpullrequestbuilder.StashPullRequestsBuilder run Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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
[JIRA] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Adding jenkins_cron_problem-10-7-2015 with all support, lsof dump, sysconfig, ect... As much as I could initially gather. Change By: Jonathan Strickland Attachment: jenkins_cron_problem-10-7-2015.zip Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-25704) Scheduled triggering stops working until restart
Title: Message Title Jonathan Strickland commented on JENKINS-25704 Re: Scheduled triggering stops working until restart Before I restart it; I have tried to turn on fine level for the hudson.trigger.Trigger and hudson.trigger.Trigger$Cron logs; nothing coming in. I plan to leave this logger on after reload. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland updated an issue Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Summary: CLOSE_WAIT sockets on failures / Pull request builder Cron based jobs are no longer working triggered Component/s: core Component/s: stash-pullrequest-builder-plugin Environment: Centos 6.6Jenkins 1.621 stash-pullrequest-builder 1.3.1 See attachment system_info.txt for full dump . Priority: Major Critical This weekend we had an auth server act up causing errors with issue was originally opened off the stash pull request builder. We no longer see logs incoming from pull requester being instantiated from -build-plugin but after further investigation we found that the cron and new pull requests are not triggering Jenkins builds system of core jenkins stop working as expected . Upon looking at Jenkins, we found a lot Approximately weekly as of close_wait sockets (meaning if I remember this correctly now with the remote end closed introduction of more cron based plugins like stash-pullrequest-builder; the connection but the client has not yet) cron system stops working . Possibly running With jenkins_debug_10072015.tar attachment; the garbage collector (I'll try after posting) may clean up the handles as the httpclient handle reference may be out system indicated for most jobs a last time polling of scope around 9:05-9:10am . All polling cron type jobs no longer responded.Very close to JENKINS-25704; almost a duplicate.
[JIRA] [stash-pullrequest-builder-plugin] (JENKINS-30558) CLOSE_WAIT sockets on failures / Pull request builder no longer working
Title: Message Title Jonathan Strickland commented on JENKINS-30558 Re: CLOSE_WAIT sockets on failures / Pull request builder no longer working Moving over to core. We saw this issue 2 times since then and found other areas of the system are impacted. The number of jobs + introduction of the cron polling to stash is putting a heavier load on system thus we are seeing the issue almost weekly now. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-30558) Cron based jobs are no longer triggered
Title: Message Title Jonathan Strickland assigned an issue to Unassigned Jenkins / JENKINS-30558 Cron based jobs are no longer triggered Change By: Jonathan Strickland Assignee: nathan m Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-25704) Scheduled triggering stops working until restart
Title: Message Title Jonathan Strickland commented on JENKINS-25704 Re: Scheduled triggering stops working until restart Finding this issue with 1.621 ... https://issues.jenkins-ci.org/browse/JENKINS-30558. When viewing some of our git polling jobs we see that they are no longer showing as polling anymore. We poll every 5 minutes for these jobs and found they were 8+ hours from last poll time. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [android-emulator-plugin] (JENKINS-27456) Emulator can't connect to adb server!?
Title: Message Title Jonathan Strickland commented on JENKINS-27456 Re: Emulator can't connect to adb server!? Related to https://issues.jenkins-ci.org/browse/JENKINS-11952 ... I see this is where a change took place to fix some instability but as noted here with the latest version downloaded from the job (Downloading and installing Android SDK from http://dl.google.com/android/android-sdk_r24.0.2-linux.tgz) the syntax localhost: doesn't appear to be valid: /android_gradle_integration_matrix/label/trust-reg-3.cisco.com $ /home/testuser/tools/android-sdk/tools/android list target [android] Using Android SDK: /home/testuser/tools/android-sdk $ /home/testuser/tools/android-sdk/platform-tools/adb start-server * daemon not running. starting it now on port 8711 * * daemon started successfully * $ /home/testuser/tools/android-sdk/platform-tools/adb start-server [android] Starting Android emulator $ /home/testuser/tools/android-sdk/tools/emulator -ports 8709,8710 -prop persist.sys.language=en -prop persist.sys.country=US -avd hudson_en-US_160_HVGA_android-16_armeabi-v7a -no-snapshot-load -no-snapshot-save -no-window -noaudio $ /home/testuser/tools/android-sdk/platform-tools/adb connect localhost:8710 unable to connect to localhost:8710: Connection refused [android] Waiting for emulator to finish booting... $ /home/testuser/tools/android-sdk/platform-tools/adb -s localhost:8710 shell getprop init.svc.bootanim error: device 'localhost:8710' not found $ /home/testuser/tools/android-sdk/platform-tools/adb connect localhost:8710 $ /home/testuser/tools/android-sdk/platform-tools/adb -s localhost:8710 shell getprop init.svc.bootanim error: device 'localhost:8710' not found $ /home/testuser/tools/android-sdk/platform-tools/adb connect localhost:8710 $ /home/testuser/tools/android-sdk/platform-tools/adb -s localhost:8710 shell getprop init.svc.bootanim error: device 'localhost:8710' not found $ /home/testuser/tools/android-sdk/platform-tools/adb disconnect localhost:8710 error: no such device 'localhost:8710' $ /home/testuser/tools/android-sdk/platform-tools/adb connect localhost:8710 $ /home/testuser/tools/android-sdk/platform-tools/adb -s localhost:8710 shell getprop init.svc.bootanim error: device 'localhost:8710' not found $ /home/testuser/tools/android-sdk/platform-tools/adb connect localhost:8710 $ /home/testuser/tools/android-sdk/platform-tools/adb -s localhost:8710 shell getprop init.svc.bootanim error: device 'localhost:8710' not found $ /home/testuser/tools/android-sdk/platform-tools/adb connect localhost:8710 $ /home/testuser/tools/android-sdk/platform-tools/adb -s localhost:8710 shell getprop init.svc.bootanim error: device 'localhost:8710' not found Run it manually on the same box with the notes from above: [testuser@trust-reg-3 ~]$ /home/testuser/tools/android-sdk/platform-tools/adb devices List of devices attached emulator-5035 device [testuser@trust-reg-3 ~]$ /home/testuser/tools/android-sdk/platform-tools/adb -s emulator-5035 shell root@android:/ # exit The fix looks as simple as the below diff; but seems we would need to either make a decision of push the throttle down to keep the train going with the latest release or add different contextes to support the older versions for those where localhost: is a more valid stable way to connect to the
[JIRA] [stash-pullrequest-builder-plugin] (JENKINS-30558) CLOSE_WAIT sockets on failures / Pull request builder no longer working
Title: Message Title Jonathan Strickland created an issue Jenkins / JENKINS-30558 CLOSE_WAIT sockets on failures / Pull request builder no longer working Issue Type: Bug Assignee: nathan m Attachments: debug_sockets.txt, jenkins_logs.txt, support_2015-09-20_20.18.47.zip, system_info.txt Components: stash-pullrequest-builder-plugin Created: 20/Sep/15 8:25 PM Environment: Centos 6.6 Jenkins 1.621 stash-pullrequest-builder 1.3.1 See attachment system_info.txt for full dump Priority: Major Reporter: Jonathan Strickland This weekend we had an auth server act up causing errors with stash pull request builder. We no longer see logs incoming from pull requester being instantiated from the cron and new pull requests are not triggering Jenkins builds. Upon looking at Jenkins, we found a lot of close_wait sockets (meaning if I remember this correctly the remote end closed the connection but the client has not yet). Possibly running the garbage collector (I'll try after posting) may clean up the handles as the
[JIRA] [lockable-resources-plugin] (JENKINS-25569) Lockable resource multi-configuration job stuck at default is still in the queue: Waiting for resources [my_resource]
Jonathan Strickland updated JENKINS-25569 Lockable resource multi-configuration job stuck at default is still in the queue: Waiting for resources [my_resource] Change By: Jonathan Strickland (17/Nov/14 1:21 AM) Summary: Lockableresource multi-configuration jobstuckatdefaultisstillinthequeue:Waitingforresources[my_resource] 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 -- 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] [lockable-resources-plugin] (JENKINS-25569) Lockable resource multi-configuration job stuck at default is still in the queue: Waiting for resources [my_resource]
Jonathan Strickland commented on JENKINS-25569 Lockable resource multi-configuration job stuck at default is still in the queue: Waiting for resources [my_resource] Seems to be only related to multi-configuration jobs. Captured some debugs: First task called is hudson.matrix.MatrixProject, then multiple hudson.matrix.MatrixConfiguration task. All initiate QueueTaskDispatcher, causing some eventual problems as seen with exhaustion of resources. 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 -- 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] [lockable-resources-plugin] (JENKINS-25569) Lockable resource job stuck at default is still in the queue: Waiting for resources [my_resource]
Jonathan Strickland commented on JENKINS-25569 Lockable resource job stuck at default is still in the queue: Waiting for resources [my_resource] Found that the QueueTaskDispatcher is being called multiple times (LockableResourcesQueueTaskDispatcher) but is appears that there is no distinction in when its being called at different points in the queue. Appears since its being called multiple times and attempting to queue up resources each time that basically get stuck waiting for resources. See below: Nov 13, 2014 11:56:51 AM INFO hudson.WebAppMain$3 run Jenkins is fully up and running Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Full stack trace is in canRun: java.lang.Thread.getStackTrace(Thread.java:1568), org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher.canRun(LockableResourcesQueueTaskDispatcher.java:41), hudson.model.Queue.isBuildBlocked(Queue.java:949), hudson.model.Queue.maintain(Queue.java:1018), hudson.model.Queue$1.call(Queue.java:316), hudson.model.Queue$1.call(Queue.java:313), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:94), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:84), java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334), java.util.concurrent.FutureTask.run(FutureTask.java:166), hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:104), java.lang.Thread.run(Thread.java:724) Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Reserve_Upgrade9k trying to reserve 1 of ASR9K Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun PROJECT FULLNAME:Reserve_Upgrade9k NAME:Reserve_Upgrade9k Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Selecting resources for queueItemId:1 queueItemProject:Reserve_Upgrade9k number:1 Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Checking resource ASR9K with project name null with queueItemsId 0 Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Validating rs ASR9K isReserved:false isLocked:false isQueue:false Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Selected size is 1 Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Reserve_Upgrade9k reserved resources ASR9K Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager lock Entering lock resources Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager lock Full stack trace is: java.lang.Thread.getStackTrace(Thread.java:1568), org.jenkins.plugins.lockableresources.LockableResourcesManager.lock(LockableResourcesManager.java:157), org.jenkins.plugins.lockableresources.queue.LockRunListener.onStarted(LockRunListener.java:48), org.jenkins.plugins.lockableresources.queue.LockRunListener.onStarted(LockRunListener.java:28), hudson.model.listeners.RunListener.fireStarted(RunListener.java:213), hudson.model.Run.execute(Run.java:1755), hudson.matrix.MatrixBuild.run(MatrixBuild.java:306), hudson.model.ResourceController.execute(ResourceController.java:89), hudson.model.Executor.run(Executor.java:240), hudson.model.OneOffExecutor.run(OneOffExecutor.java:43) Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager lock Exiting lock resources with true Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Full stack trace is in canRun: java.lang.Thread.getStackTrace(Thread.java:1568), org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher.canRun(LockableResourcesQueueTaskDispatcher.java:41), hudson.model.Queue.isBuildBlocked(Queue.java:949), hudson.model.Queue.maintain(Queue.java:1018), hudson.model.Queue$1.call(Queue.java:316), hudson.model.Queue$1.call(Queue.java:313), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:94), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:84), java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334),
[JIRA] [lockable-resources-plugin] (JENKINS-25569) Lockable resource job stuck at default is still in the queue: Waiting for resources [my_resource]
Jonathan Strickland created JENKINS-25569 Lockable resource job stuck at default is still in the queue: Waiting for resources [my_resource] Issue Type: Bug Assignee: Unassigned Components: lockable-resources-plugin Created: 12/Nov/14 2:44 PM Description: We allocated two resources (routers in our environment). When we kick off the job we see the resource is allocated, but the job stays in a "waiting for resource state" indefinitely. I have included debug images of the global resource configuration, job, and job output. Environment: Jenkins ver. 1.589 Lockable Resources plugin 1.5 Project: Jenkins Labels: plugin lockable Priority: Major Reporter: Jonathan Strickland 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 -- 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] [lockable-resources-plugin] (JENKINS-25569) Lockable resource job stuck at default is still in the queue: Waiting for resources [my_resource]
Jonathan Strickland updated JENKINS-25569 Lockable resource job stuck at default is still in the queue: Waiting for resources [my_resource] Change By: Jonathan Strickland (12/Nov/14 2:47 PM) Attachment: lock_debug_images.zip 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 -- 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.
