RTC 3.0.1 z/OS Build Engines, BFAGENT and Concurrency
How are multiple build engines and bfagents used to support concurrent execution of build requests? I have tested out having 2 bfagents and 2 corresponding build engines thinking that if 2 developers submitted a build request at the same time each using a separate build definition tied to to separate build engines/bfagents that they would execute concurrently. Even under those circumstances the "first one in" started execution and the second one went into a pending state until the first one completed. From a performance perspective how do you structure to handle a 100 developers where at any point in time a number of them may be requesting builds.
6 answers
How are multiple build engines and bfagents used to support concurrent execution of build requests? I have tested out having 2 bfagents and 2 corresponding build engines thinking that if 2 developers submitted a build request at the same time each using a separate build definition tied to to separate build engines/bfagents that they would execute concurrently. Even under those circumstances the "first one in" started execution and the second one went into a pending state until the first one completed. From a performance perspective how do you structure to handle a 100 developers where at any point in time a number of them may be requesting builds.
This work item may be the same behavior that you're noticing.
Brent Ulbricht
How are multiple build engines and bfagents used to support concurrent execution of build requests? I have tested out having 2 bfagents and 2 corresponding build engines thinking that if 2 developers submitted a build request at the same time each using a separate build definition tied to to separate build engines/bfagents that they would execute concurrently. Even under those circumstances the "first one in" started execution and the second one went into a pending state until the first one completed. From a performance perspective how do you structure to handle a 100 developers where at any point in time a number of them may be requesting builds.
This work item may be the same behavior that you're noticing.
Brent Ulbricht
So this has been included in the current 3.5M3 milestone? And will it allow parallel concurrent execution as in the scenario I described? One more queston - if two agents are both being used by definitions that output to the same z/OS PDS datasets - will the get into a problem on output where one or both get cancelled?
Looking at the work item Brent linked to... it is resolved and was targeted for M2 so I think the answer would be yes, it is in the m3 driver. Reading the defect and the comment thread it seems to me that this is the scenario you are describing.
Guy
So will this be part of 3.5 due out in the Spring - or will it be in one of the fix PTFs?
Note that 3.5 is currently scheduled for summer 2012 (June). Fix pack 2
(3.0.1.2) is currently scheduled for Dec 2011, and Fix pack 3 (3.0.1.3)
is currently scheduled for April 2012.
Cheers,
Geoff
On 11/3/2011 7:38 AM, dpoulin wrote:
(3.0.1.2) is currently scheduled for Dec 2011, and Fix pack 3 (3.0.1.3)
is currently scheduled for April 2012.
Cheers,
Geoff
On 11/3/2011 7:38 AM, dpoulin wrote:
gsladewrote:
Looking at the work item Brent linked to... it is resolved and was
targeted for M2 so I think the answer would be yes, it is in the m3
driver. Reading the defect and the comment thread it seems to me that
this is the scenario you are describing.
Guy
So will this be part of 3.5 due out in the Spring - or will it be in
one of the fix PTFs?
So will this be part of 3.5 due out in the Spring - or will it be in one of the fix PTFs?
If you take a second to look at the work item that Brent linked to you will see it contains a 'mentioned by' link to a second defect that is targeted for 3.0.1.2.
If you look at this you will see that it has been triaged but not implemented yet. So based on this, I would take an educated guess and say that it is definitely in the 3.5 release and is currently planned to be back ported to the 3.0.1.2 release but this is not a guarantee since there is only one more 3.0.1.2 milestone left. I would comment on this second defect to make sure Brent knows that you would like it in the fixpak (assuming you would like it in the fixpak).
Guy