Hi

the documentation is rather clear,
http://confluence.public.thoughtworks.org/display/CCNET/Queue+Configuration

but here it goes ;-)

duplicate tag : handles what to do when a project is more than once in the
queue, AND the project is a force build

Scenario : when there are a lot of projects in the queue :
A B C A D E

the first A is being built now, the second is waiting

now suppose A is triggered again(forced), so it must be added to the queue
now the duplicate tag kicks in

use first : just add A to the list
  so the queue is like follows
   A B C A D E A


ApplyForceBuildsReplace
 A B C A D E

A is not appended, because it is already in the queue, it replaces the
existing one

ApplyForceBuildsReAdd
   A B C D E A

 A is re-added to the queue, but the existing one is removed from it



I hope I am 100% correct about this, I have not tested this

with kind regards
Ruben Willems




On Wed, Mar 11, 2009 at 8:34 AM, jonty s <[email protected]> wrote:

> <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
>>>
>>
>>
>>
>>
>

Reply via email to