On Wed, Dec 10, 2014 at 5:20 AM,  <[email protected]> wrote:
> We don't provision new slaves; we have a number of existing machines in a
> build farm that we connect to. Hence I don't think a cloud is a solution

By “provision” I merely mean “start a new slave connection”. Where the
actual hardware comes from is irrelevant from that perspective; what
matters is that a new Slave appears in Jenkins on demand. You can
certainly use a Cloud implementation within a predetermined hardware
pool, as for example
http://jenkins-enterprise.cloudbees.com/docs/user-guide-docs/vmware-sect-cloud.html
does.

>                 at hudson.model.Queue.getBuildableItems(Queue.java:758)
>                 - waiting to lock <0x00000000c1e0e998> (a hudson.model.Queue)
>                 at 
> hudson.slaves.RetentionStrategy$Demand.check(RetentionStrategy.java:224)
>                 - locked <0x00000000c2ef23d8> (a 
> hudson.slaves.RetentionStrategy$Demand)
>                 at 
> hudson.slaves.RetentionStrategy$Demand.check(RetentionStrategy.java:172)

This sounds similar to a well-known deadlock pattern as fixed for the
EC2 plugin in https://issues.jenkins-ci.org/browse/JENKINS-22558
though I am not sure yours is the same—you have clipped off the
crucial portions of the thread dump that would display the reason for
the deadlock. I would advise that you file an issue for your deadlock,
attach the unabridged thread dump as a file (not inline! loses
formatting, makes the issue too long), link to JENKINS-22558 for
reference, and hope someone familiar with this part of the Jenkins
codebase analyzes it. I suspect the listener plugin you mentioned
(whatever that is) is responsible somehow. (By the way implementing
this kind of thing in JRuby seems like a poor idea to me.)

The threading-related bugs Stephen mentioned are quite distinct from
this, I think, and manifest themselves as race conditions rather than
deadlocks.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3Zp87-dBzw%3DzAzjLv6MzVYZPscF8ob0CmsLHRw17Kn6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to