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" <[email protected]> wrote:

>On May 10, 2013, at 5:39 PM, Dean Yu <[email protected]> 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 [email protected].
>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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to