Build Engines, Build Agents, and all that jazz…

Today I’d like to attempt to clarify a couple points of confusion surrounding the Rational Build Agent that is used for all of the Enterprise Extensions builds (Ant EE build, dependency build, promotion, packaging, and deployment) in RTC.

First off is the notion of the “Build Agent” versus the “Build Engine” and how many of each you might need. The “Build Agent” is the actual instance of the Rational Build Agent running on the build machine that is responsible for executing requested builds. The “Build Engine” is an artifact created in the RTC repository (found in the Team Artifacts view under Builds->Build Engines), owned by a particular team or project area, that specifies the host name and port where the build agent is running (among other things). The build agent itself is multithreaded, meaning it can service multiple build requests at once. So if you have several different build definitions supported by a single agent, requests from each of those definitions can be processed in parallel. However, the build engine is single threaded. This means that if each of your build definitions points to the same build engine, only one single request from all of the definitions can be processed at a time. The build engine blocks as busy until the requested build it is servicing completes. Therefore, if you do not want requests for build definition A held up by requests for build definition B, you could create a dedicated build engine for each build definition or specify a pool of build engines that support your build definitions. Those build engines can then point at different build agents on different build machines, different build agents on the same build machine, or one one single build agent instance that can handle requests from all definitions in parallel. More on the round-robin distribution of build requests and other build agent topics can be found here.

Now that we’ve sorted out one possible bottleneck, I must mention another. When a build is requested, a certain amount of processing occurs on the server before the request is passed over to the build agent running on the build machine. For example, when a dependency build runs, a pre-processor running on the server determines which programs will be rebuilt based on what files have changed. This list of programs is then transferred to the build machine to be built. If you are running with a version prior to, you will discover that while your dependency build is chugging through trying to figure out what needs to be rebuilt, NO other builds supported by ANY Rational Build Agent will be processed. This is because the service responsible for handling build requests was waiting for all of the pre-processing for each build request to complete before moving on to the next. Fortunately this has been fixed, and details can be seen in BuildAgentRequestService participants should be multi-threaded (171210).

Another source of confusion is the misleading “Build engine process polls for requests” checkbox in the Overview tab of the Build Engine editor. This tab is common to both the Rational Build Agent engines and the Jazz Build Engine (JBE) engines, but this particular setting only really makes sense for the latter. The JBE, unlike the Rational Build Agent, spins in a loop and continuously asks the server “do you have anything for me now? … how ’bout now? … how ’bout now??” This setting tells the server that the JBE is engaging in this behavior and will be servicing build requests. While the Rational Build Agent does NOT poll the server checking for build requests, you DO still need to have this box checked off in order for your engine to process build requests. Confusing.

Perhaps the most confusing aspect of the Rational Build Agent engine is figuring out what userid your build is running under. This is influenced by a number of factors, including how your build agent is started, whether you are using magic logon, and whether you are using build agent authentication overrides. For this, I point you to an excellent reference available on the wiki.

I hope this helps to some extent, and I realize I’ve really only scratched the surface of topics in this area. If there are specific topics you’d like to see addressed, or things that were not fully clarified here, please comment back!

This entry was posted in Enterprise Extensions, Rational Team Concert, System z. Bookmark the permalink.

2 Responses to Build Engines, Build Agents, and all that jazz…

  1. Pingback: Build Artifacts Publishing and Automated Build Output Management Using the Plain Java Client Libraries | rsjazz

  2. Pingback: Performance Testing the Rational Build Agent – Strongback Consulting

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s