QB3.0.14: Suggestion on serializing one step #1332

scastria · 1 decade ago

I have 74 build agents each running multiple builds per day as part of a large 100 configuration trigger chain. I have a new step that I need to add to my master build workflow that requires it be executed in serial with regard to all other simultaneous builds that may execute that step. This is analogous to a multi-threaded programming problem where multiple threads are accessing a common method, but that method is not thread safe. Therefore, in Java, I would add the synchronize keyword. What can I do in QB to prevent this one step from being executed more than once at a time? Is there a way to synchronize a step?

replies 3
views 1052
stars 0

robinshen ADMIN · 1 decade ago

The resource lock can be used to address this issue:
http://wiki.pmease.com/display/QB31/Lim ... bs+on+Node

In your case, concurrency of the step is 1.

scastria · 1 decade ago

Looking more closely at the resource locking documentation, it seems like it is per node. I need to synchronize a single step across ALL BUILDS and ALL NODES so that at any one instant, only one node can be running my step for any build. Do I make this a server side resource to accomplish this??

I tried changing the code to:

groovy:
grid.serverNode.getResource("p2.publish",new java.util.concurrent.Semaphore(1)).acquire();

groovy:
grid.serverNode.getResource("p2.publish").release();

But I get the following exception:

com.pmease.quickbuild.QuickbuildException: Resource of node 'buildmaster3:8080' can only be accessed from the script running on node 'buildmaster3:8080'.

Will I have to surround my step with a pre step and a post step each with node match set to server??

scastria · 1 decade ago

I moved the getResource groovy scripts to the parent step and forced that parent step to run on the server. That essentially makes this resource lock owned by the server for all nodes that run the child step to achieve what I want. It seems to work great! Again, I am amazed at the functionality of QB. I had planned 2 days to fix this issue not knowing that QB had a built in feature to solve it within 10 minutes.