Next time this is happening, capture a thread dump of the master and all the slaves by going to the URL:
http://<yourJenkinsServer>/threadDump We should be able to tell from the thread dump what the SCM polling thread is getting blocked on. -- Dean On 5/13/13 11:53 AM, "David Shaw" <ds...@jabberwocky.com> wrote: >On May 10, 2013, at 5:39 PM, Dean Yu <dean...@gmail.com> wrote: > >> On Thursday, May 9, 2013 1:02:58 PM UTC-7, Mandeville, Rob wrote: >> I believe that the behavior you are seeing is by design. The >>concurrent builds checkbox allows you to run multiple instances of that >>job at all, but the SCM poller will only launch one at a time. >>Basically, with the checkbox you could kick off as many builds as you >>wanted manually. >> >> This isn't quite right. SCM polling is independent of individual >>builds. The fact that SCM polling is blocked while a build is in >>progress sounds like a bug in the Mercurial plugin. >> >> What should be happening is that every half hour, Jenkins will poll >>your configured source location in Mercurial for changes. If there are >>changes, a new build is scheduled into the build queue. If the project >>is not marked as able to run concurrently, and there is no in progress >>build of the job, and there is an available executor, then the new build >>will start. If there is a build of the job in progress, the new build >>will wait in the queue until the previous build completes. If, at the >>next polling interval, there is yet another change detected, and the >>first build is still in progress, the build in the queue is updated to >>check out from the new revision. In other words, there is normally only >>one outstanding build of the project in the queue at a time. >> >> If the project is configured to run concurrently, Jenkins will assign >>the build to an available executor, even if another build of the same >>project is still in progress. > >Unfortunately, this isn't what is happening. The job is configured to >run concurrently, but the second build isn't queued until the first build >completes. > >> Yet another possibility is if you have some mutex or semaphore >>configured (via Throttle Concurrent Builds, Port Allocator, Locks and >>Latches, or some similar plugin), and that is preventing multiple builds >>from running at once. > >I'm not using any of those plugins. To test, I set up a Jenkins install >with no plugins (aside from Mercurial and the ones that are shipped with >Jenkins). It still happens. > >Any thoughts on how to debug this further? I'm okay with the workaround >that Rob Mandeville suggested, but if it's a bug, better to get it fixed >than rely on a workaround forever. > >David > >-- >You received this message because you are subscribed to the Google Groups >"Jenkins Users" group. >To unsubscribe from this group and stop receiving emails from it, send an >email to jenkinsci-users+unsubscr...@googlegroups.com. >For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
