Concurrent builds on build server?

I'm creating build definitions, and I noticed that I've specified the same "Load directory" value for all of them, each with the "Delete directory before loading" option checked.
This seems fine as long as no two builds will ever run concurrently.
Is there ever risk/opportunity for two builds to run concurrently on a build server? Is it particularly good/bad to have two build definitions use the same load directory?
This seems fine as long as no two builds will ever run concurrently.
Is there ever risk/opportunity for two builds to run concurrently on a build server? Is it particularly good/bad to have two build definitions use the same load directory?
7 answers

On 2010/11/02 9:38, lancehilliard wrote:
Two builds may run concurrently on a build server if you run two
different build engines (a.k.a. JBE) processes on the build server.
Each build engine process will run only one build at a time. So if you
have just one build engine running on the machine, only one build at a
time will run on that machine.
As long as things are configured so that only one build at a time runs
on a machine, then having all the build definitions using the same load
directory should be fine.
If you want to run multiple builds at the same time, then you will need
to change the way that you handle load directories. If two builds
running at the same time try to share a single load directory, bad
things will happen.
One possible way to deal with this is to define a property in every
build engine definition that specifies the load directory. Every build
engine would define the same property, but they would all have a
different value. Then every build definition would use that property in
the load definition field.
For example, build engine BE_A would define the property
loadDirectory=/build/workspaces/be_a
Build engine BE_B would define the property
loadDirectory=/build/workspaces/be_b
And every build definition would simply have "${loadDirectory}" in the
Load directory field.
I'm creating build definitions, and I noticed that I've specified the
same "Load directory" value for all of them, each with the
"Delete directory before loading" option checked.
This seems fine as long as no two builds will ever run concurrently.
Is there ever risk/opportunity for two builds to run concurrently on a
build server? Is it particularly good/bad to have two build
definitions use the same load directory?
Two builds may run concurrently on a build server if you run two
different build engines (a.k.a. JBE) processes on the build server.
Each build engine process will run only one build at a time. So if you
have just one build engine running on the machine, only one build at a
time will run on that machine.
As long as things are configured so that only one build at a time runs
on a machine, then having all the build definitions using the same load
directory should be fine.
If you want to run multiple builds at the same time, then you will need
to change the way that you handle load directories. If two builds
running at the same time try to share a single load directory, bad
things will happen.
One possible way to deal with this is to define a property in every
build engine definition that specifies the load directory. Every build
engine would define the same property, but they would all have a
different value. Then every build definition would use that property in
the load definition field.
For example, build engine BE_A would define the property
loadDirectory=/build/workspaces/be_a
Build engine BE_B would define the property
loadDirectory=/build/workspaces/be_b
And every build definition would simply have "${loadDirectory}" in the
Load directory field.

Hi Lance,
you should only run one JBE and then you will never have two builds running at the same time. The next build is started once the current request has finished.
Ralph
you should only run one JBE and then you will never have two builds running at the same time. The next build is started once the current request has finished.
Ralph
I'm creating build definitions, and I noticed that I've specified the same "Load directory" value for all of them, each with the "Delete directory before loading" option checked.
This seems fine as long as no two builds will ever run concurrently.
Is there ever risk/opportunity for two builds to run concurrently on a build server? Is it particularly good/bad to have two build definitions use the same load directory?

I'm creating build definitions, and I noticed that I've specified the same "Load directory" value for all of them, each with the "Delete directory before loading" option checked.
This seems fine as long as no two builds will ever run concurrently.
Is there ever risk/opportunity for two builds to run concurrently on a build server? Is it particularly good/bad to have two build definitions use the same load directory?
I have never had two builds run concuuently. You want to avoid this if you can.

We recently upgraded from RTCv2 to v3.0.0iFix1. There was a recent situation where one of our builds failed horribly. Upon investigation, it appears that a single build engine was running two builds at the same time (i.e., two separate instances of 'make' were running in the same directory). It happened at a rare point where all the build engines were busy.
Does RTCv3 allow for a single build engine (jbe) to run more than one build concurrently?
Thanks!
P.S.: we have a single server running 10 build engines. Each build engine has a separate RTC build engine ID, a separate jbe JVM, a separate Linux userid, a separate $HOME directory, and the load directory is relative to $HOME. It's been working great for us. We started with 2 build engines and added more as our needs grew. So yes, we can do 10 builds in parallel, a combination of scheduled and personal builds, even builds from different streams. The isolation works great.
Does RTCv3 allow for a single build engine (jbe) to run more than one build concurrently?
Thanks!
P.S.: we have a single server running 10 build engines. Each build engine has a separate RTC build engine ID, a separate jbe JVM, a separate Linux userid, a separate $HOME directory, and the load directory is relative to $HOME. It's been working great for us. We started with 2 build engines and added more as our needs grew. So yes, we can do 10 builds in parallel, a combination of scheduled and personal builds, even builds from different streams. The isolation works great.