On Tue, Oct 18, 2016 at 12:10 PM, Surya Gaddipati
> neither concerrentmodificationexception nor scheduling
> on zombie node are applicable here .
If you are bypassing a lock, a CME seems like a risk.
> a patch to core that adds nodes to jenkins
> without unnecessary queue locking.
Sounds like the wrong approach to me. For the short term Stephen’s advice was
> For now, use the queue lock methods, when we remove the need for a lock they
> will become no-ops that the JVM will inline away for plugins compiled against
> current cores
The real fix would be to bypass `Queue` altogether for these cases and
inline all the launching and remoting into the lifecycle of the build
itself. The main issue is that there are some places in Jenkins core
where it is assumed that a valid `Node`/`Computer` is also in the
global lists, which is not something you want here. You can create a
`FilePath` and `Launcher` not tied to a `Node` or `Computer`, but that
is also poorly supported in various places. So I think a larger
redesign is necessary. Adding a one-off method which is not in general
safe to call would just make a compatible transition harder.
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 view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.