Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53320

Job fails because JiraSCMListener times out on too many changes

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      If there are too many changes (in our case more than 1000 commits), the JiraSCMListener times out and fails the job.

      java.util.concurrent.TimeoutException: Timeout waiting for task.
      	at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:259)
      	at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:91)
      	at com.google.common.util.concurrent.ForwardingFuture.get(ForwardingFuture.java:69)
      	at com.atlassian.jira.rest.client.internal.async.DelegatingPromise.get(DelegatingPromise.java:107)
      	at hudson.plugins.jira.JiraRestService.getIssuesFromJqlSearch(JiraRestService.java:177)
      	at hudson.plugins.jira.JiraSession.getIssuesFromJqlSearch(JiraSession.java:136)
      	at io.jenkins.blueocean.service.embedded.jira.JiraSCMListener.onChangeLogParsed(JiraSCMListener.java:43)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.onCheckout(WorkflowRun.java:1036)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.access$1400(WorkflowRun.java:143)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun$SCMListenerImpl.onCheckout(WorkflowRun.java:1239)
      	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:127)
      	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
      	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
      	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
      	at hudson.security.ACL.impersonate(ACL.java:290)
      	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      	at java.lang.Thread.run(Thread.java:745)
      

        Attachments

          Activity

          Hide
          alecharp Adrien Lecharpentier added a comment -

          This is reproductible on a Jenkins 2.121.3 with BlueOcean Jira 1.7.1. There is no problem with BlueOcean Jira 1.5.1.

          Show
          alecharp Adrien Lecharpentier added a comment - This is reproductible on a Jenkins 2.121.3 with BlueOcean Jira 1.7.1 . There is no problem with BlueOcean Jira 1.5.1 .
          Hide
          mbmop Mostyn Bramley-Moore added a comment -

          We're also hitting this bug, with JIRA Integration for Blue Ocean version 1.8.2.

          Show
          mbmop Mostyn Bramley-Moore added a comment - We're also hitting this bug, with JIRA Integration for Blue Ocean version 1.8.2.
          Hide
          olamy Olivier Lamy added a comment - - edited

          Patrick Ruckstuhl  Mostyn Bramley-Moore  does all commit relates to same Jira issue or is it a lot of Jira issues?

          And did you try increasing timeout?

          Show
          olamy Olivier Lamy added a comment - - edited Patrick Ruckstuhl   Mostyn Bramley-Moore   does all commit relates to same Jira issue or is it a lot of Jira issues? And did you try increasing timeout?
          Hide
          olamy Olivier Lamy added a comment -

          btw a very simple improvement is to improve the jql query construction for duplicate keys.

          ATM if 2 changelog entries have TEST-123 as Jira issue, the generated jql is 

          key in ('TEST-123', 'TEST-123') 

          which is definitely not optimum.

          Show
          olamy Olivier Lamy added a comment - btw a very simple improvement is to improve the jql query construction for duplicate keys. ATM if 2 changelog entries have TEST-123 as Jira issue, the generated jql is  key in ( 'TEST-123' , 'TEST-123' ) which is definitely not optimum.
          Hide
          olamy Olivier Lamy added a comment -

          current default timeout is 10s maybe we can increase this default value? (30s)

          Show
          olamy Olivier Lamy added a comment - current default timeout is 10s maybe we can increase this default value? (30s)
          Hide
          tario Patrick Ruckstuhl added a comment -

          For me it was lots of different issues and I somehow missed the timeout setting.

          Show
          tario Patrick Ruckstuhl added a comment - For me it was lots of different issues and I somehow missed the timeout setting.
          Hide
          olamy Olivier Lamy added a comment -

          Patrick Ruckstuhl no worries. Let us know if changing the timeout improves something?

          Show
          olamy Olivier Lamy added a comment - Patrick Ruckstuhl no worries. Let us know if changing the timeout improves something?
          Hide
          tario Patrick Ruckstuhl added a comment -

          I unfortunately can't test this scenario anymore. It was basically a merge on a branch which was innactive for a couple of months. My solution to work around this problem was to uninstall the blueocean plugin.

          Show
          tario Patrick Ruckstuhl added a comment - I unfortunately can't test this scenario anymore. It was basically a merge on a branch which was innactive for a couple of months. My solution to work around this problem was to uninstall the blueocean plugin.
          Hide
          mbmop Mostyn Bramley-Moore added a comment -

          I will try tweaking our timeout setting, but won't be able to test this immediately.

          Still, it seems a bit strange that a display plugin should be able to break a build like this. I wonder if the build would still have failed if I didn't have blueocean installed?

          Show
          mbmop Mostyn Bramley-Moore added a comment - I will try tweaking our timeout setting, but won't be able to test this immediately. Still, it seems a bit strange that a display plugin should be able to break a build like this. I wonder if the build would still have failed if I didn't have blueocean installed?
          Hide
          olamy Olivier Lamy added a comment -

          well the build should not fail which is the problem..

          Show
          olamy Olivier Lamy added a comment - well the build should not fail which is the problem..
          Hide
          vivek Vivek Pandey added a comment -

          Olivier Lamy Yeah timeout exception should not fail a build. That needs to be fixed.

          Show
          vivek Vivek Pandey added a comment - Olivier Lamy Yeah timeout exception should not fail a build. That needs to be fixed.
          Hide
          olamy Olivier Lamy added a comment -

          Vivek Pandey this pr will avoid to fail the build  https://github.com/jenkinsci/blueocean-plugin/pull/1816  .

          Can be a first workaround quick fix until better changes in Jira plugin.

          But anyway we need this as timeout can happen all the time while querying Jira so we must not fail the build in this case...

          Show
          olamy Olivier Lamy added a comment - Vivek Pandey this pr will avoid to fail the build   https://github.com/jenkinsci/blueocean-plugin/pull/1816   . Can be a first workaround quick fix until better changes in Jira plugin. But anyway we need this as timeout can happen all the time while querying Jira so we must not fail the build in this case...
          Hide
          vivek Vivek Pandey added a comment -

          Olivier Lamy AFAIK, these listeners are async process, running in separate thread, a runtime exception can fail that listener, shouldn’t fail the build thought. cc: Jesse Glick

          Show
          vivek Vivek Pandey added a comment - Olivier Lamy AFAIK, these listeners are async process, running in separate thread, a runtime exception can fail that listener, shouldn’t fail the build thought. cc: Jesse Glick
          Hide
          olamy Olivier Lamy added a comment -

          corresponding Jira plugin pr is here https://github.com/jenkinsci/jira-plugin/pull/166 

          Show
          olamy Olivier Lamy added a comment - corresponding Jira plugin pr is here https://github.com/jenkinsci/jira-plugin/pull/166  
          Hide
          jglick Jesse Glick added a comment -

          these listeners are async process, running in separate thread

          Acc. to the stack trace the problem occurs synchronously in the step execution thread.

          Show
          jglick Jesse Glick added a comment - these listeners are async process, running in separate thread Acc. to the stack trace the problem occurs synchronously in the step execution thread.

            People

            • Assignee:
              olamy Olivier Lamy
              Reporter:
              tario Patrick Ruckstuhl
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: