Is there any roadmap for it? On Tuesday, October 18, 2016 at 7:48:43 PM UTC+3, Jesse Glick wrote: > > On Tue, Oct 18, 2016 at 12:10 PM, Surya Gaddipati > <[email protected] <javascript:>> wrote: > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7123adbe-bae2-4a49-aec2-8826b8fc0e0a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
