<Adding ccnet-user too to get a perspective of real projects using queue's>
So priority is more about sequencing the builds. Gotcha!! *Duplicate Tag* duplicates="UseFirst", why would someone configure duplicates ? So if incorrectly configure my build sequence I might get duplicate entries. To fix this contention we have duplicates to resolve contention. Right ? No other reason. If I have 2 projects in Q1 with the same priority, then it should flag a error right ? Since its not able priority, but sequencing instead. Why would someone want to use duplicates="ApplyForceBuildsReplace" OR duplicates="ApplyForceBuildsReAdd". Wont this result in a unpredictable state of the build ? *Lock Tag* Will the config catch a circular lock ? Why do we have lock's, dont priority handle the sequencing problem ? What if I lock B when running A, but instead prioritize B to run earlier than A ? Do we handle this circular deadlock ? Please advice Siddharth On Wed, Mar 11, 2009 at 12:23 PM, Matt Chatterley <[email protected] > wrote: > Hiya, > > I think Craig is right - queues definitely handle both of these, and were > implemented for a number of reasons - I certainly made some tweaks to them > for resource contention issues, too. :) > > Siddharth - what is the problem you are trying to solve? > > Scenario 1 will depend not only on queues, but on the priority of the > problematic project. > > Scenario 2 - yes, queues can handle dependency issues, by pipelining (as > Craig said) builds into a line. > > Basically you can use queues (and queue locking) to stop certain > combinations of projects building in parallel. E.g. If you have two > projects, A+B, and B includes A - you would put them both in a queue, set > the priority on B to be logically lower (numerically higher) than A, and off > you go. > > Does that help? > > > > > -- > Matt Chatterley > Mattched IT Ltd > http://www.mattchedit.com > UK Registered Company: 05861949 > > > 2009/3/11 Craig & Sammi Sutherland <[email protected]> > >> Hi Siddharth, >> >> >> >> Queues would handle both of these scenarios, but I think the main reason >> queues were implemented was to reduce resource contention. Putting multiple >> projects in a queue means only one project can access the resources at any >> time. >> >> >> >> They also help group related projects together into a “pipeline” type >> scenario, e.g. project one compiles the code, while project two tests it. >> You wouldn’t want project one to start compiling the code again while >> project two is still testing. >> >> >> >> These are just based on my understanding, as I was not the original >> developer. >> >> >> >> >> >> Craig >> >> >> >> *From:* [email protected] [mailto:[email protected]] >> *On Behalf Of *jonty s >> *Sent:* Wednesday, 11 March 2009 7:21 p.m. >> *To:* [email protected]; [email protected] >> *Subject:* [ccnet-devel] Build Queue Scenarios >> >> >> >> Here Im trying to understand the scenarios of build queue. >> >> Why do queue's exist in the first place ? >> >> Scenario1 : Is it because its possible for a build to start again (due to >> scheduling) without a earlier build completing ? >> >> Scenario2 : Queues help control the dependencies between independent >> builds ? Web application build is dependent on web server build completing. >> >> ??? >> >> Please give me a few pointers to understnad the problem we are tryng to >> solve using queues. >> >> Regards >> >> Siddharth >> > > > >
