Forum Discussion

bhasha's avatar
Occasional Contributor
7 years ago

Does the clone method for TestSteps lock the request being cloned?

I am executing test cases in parallel.  Instead of having the requests in each test case I drive them using Groovy. 


I have a set of base requests that the test cases share.  When the test case uses a request it clones the request from the base requests to it's test case, executes it, and then deletes it.


I believe the clone method is locking the request so when two test cases attempt to clone the base request at the EXACT same time then they both fail.


So I have two questions:

Has anyone else experienced this? 

Is there a way to do a read-only lock so that the clone can be executed more than once at the exact same time?


Thanks in advance for your time.

2 Replies

  • JHunt's avatar
    Community Hero

    I have encountered a similar problem. I have a theory that the problem is because SoapUI doesn't want you to modify the project (add/remove model items such as requests, test steps, etc) in multiple threads at the same time, since internally the whole project is just one big xml document, and when I had the problem I was seeing in the error log "XmlDisconnectedException" whenever things were failing.


    One potential solution is instead of cloning the TestRequests (in a TestCase), you just having GroovyTestSteps that submit existing Requests (inside the interface).


    First, your script should set some variables in the TestRunContext to use in the request:


    context.with {
    	username = "Login"
    	password = "Login123"

    Your requests can use context variables directly:

    <soapenv:Envelope xmlns:soapenv="" xmlns:sam="">

    Then submit, making use of the current TestRunContext:


    submitResult = context.testCase.project
     .getRequestByName("login rq")
     .submit(context, false)

    Now that you're using Requests rather than TestRequests, you can't use SoapUI's assertions any more, but you can still get hold of the response and make your own:


     .with { String response ->
    	new XmlSlurper()
    	 .with {Envelope -> assert Envelope.Body.Fault.faultstring == "Already Login"}


    • bhasha's avatar
      Occasional Contributor

      That seems like a feasible work around.  However, I don't think we're in a position to overhaul things to work this way.  We've already spent a considerable amount of time getting where we are now.


      I attempted to implement what seems to be a feasible work around.  I'm forcing it to sleep a random amount of time between 1-5 seconds and then attempt the re-clone if there is an exception.