Multiple JBE instances using same engine ID
Is it okay to use multiple JBE instances with the same engine ID? We are currently doing so and don't appear to be having problems. We have all of our build definitions using one engine. Then, we have a shell script that starts up one or more JBE instances each with its own work directory (so that builds don't collide).
We realize that we could have all of our build definitions explicitly declare multiple supported build engines. But, if we want to scale this up or down, we'd have to edit all of our build definitions to add or remove engines. With the shell script, we can easily re-configure the number of build engines without having to modify the build definitions. It has been working great, but wanted to check in case anyone knows of issues in doing so. Our administrator has noticed this error message periodically. Could this be related to having multiple engines with the same ID? 1 row was expected but 0 rows were found for handle "com.ibm.team.build.internal.common.model.impl.BuildEngineActivityImpl |
4 answers
We don't see any problem as we often instantiate build engine instances in different machines to share the load of the build process. Instantiating multiple JBE instances in a single machine that listens to the same engine ID but targeting different local workspaces shouldn't pose any problem except if the machine is not powerful enough to support the concurrent JBE instances.
I am not sure but the error might be related to two instances querying for work at the same time, receiving a reply that there is one request in the queue, instance1 popping out the request and start the build, and then instance2 generates an error when it gets an empty queue as a response to its request to have the build request allocated to it. ciao! |
While it 'mostly works', it's not recommended to run multiple jbe processes for the same engine id.
The error you're seeing is likely due to concurrent requests from the jbe processes when the request tries to update the engine's last contact time (stored in a BuildEngineActivity item). If it fails, we retry the update several times, which usually works even under heavy load, so you should not normally see this message. It's possible you hit a known defect (fixed recently in 2.0), where this item could become permanently stale, even when using only one jbe. For more details, see 62896: StaleDataException when attempting to update the last contact time while retrieving the next request. Further, information in the client will be inaccurate or misleading, such as the busy state of a build engine, the last contact time, or whether an engine is being responsive. We're also considering having jbe clean up (i.e. mark as abandoned) any in-progress builds for that engine when it starts, or even between requests. Builds can currently get stuck in an in-progress state if there's an error communicating a state change (like build completion) back to the server, or if the jbe process is killed in the middle of a build. Multiple jbe processes for the same engine id wouldn't play well with this change. For more details, see 78579: In-progress builds left in in-progress state if build engine restarted. |
With the shell script, we can easily re-configure the number of build engines without having to modify the build definitions. It has been working great, but wanted to check in case anyone knows of issues in doing so. A colleague of mine pointed out that you don't actually need to edit every build definition. Instead, you can edit the build engine. In that editor, you can easily select which build definitions run on that engine. That is pretty convenient, so one could scale without much hassle. For example, if more build capacity is needed, a new build engine could be created. As part of that, one would select the build definitions that they wanted to run on it. This would get us back to using one JBE instance per build engine ID. |
|
Good, glad to hear that helps.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.