Forum Discussion

jgoguen's avatar
jgoguen
Occasional Contributor
8 years ago
Solved

Long delay causes test to hang

I'm currently using SoapUI 4.5.1 testrunner.sh to run some duration tests over the course of 8 hours on the command line. I have a few requests separated by delay test steps of 13 or so minutes. The test always hangs at some point while running, though not always in the same place and not always on the delays. When I put the delays down to 2 seconds, the test runs all the way through to the end just fine. I have tried replacing the delay test steps with groovy steps that call Thread.sleep. I have even tried breaking the delays up into individual groovy test steps that sleep for 30 seconds until the desired delay has been achieved. So far none of these attempts have not resulted in failure.

 

Is this a known issue? Is there a workaround?

 

Thanks

  • jgoguen's avatar
    jgoguen
    8 years ago

    So, I've gone through several iterations rearranging and running tests, and I think I may have discovered a way to get my tests to run without hanging or crashing. My latest permutation breaks out any delay longer than 30 seconds to its own test suite. I've run several times without any SoapUi issues. I'm not sure if the problem happens when a test suite runs for too long or if it's because there are several long delays spread out over one test suite, but it did hang pretty reliably before I changed it to the current strategy. It's an interesting problem that I'd like to spend more time testing to find the specific combination that reproduces it, but SmartBear doesn't pay me enough for that. XD

8 Replies

Sort By
  • kondasamy's avatar
    kondasamy
    Regular Contributor
    8 years ago

    Can you please try running with the recent version - SoapUI 5.2.1 and let us know what you see.

     

    Thanks,

    Kondasamy

    • jgoguen's avatar
      jgoguen
      Occasional Contributor
      8 years ago

      I do have access to SoapUI 5.2.1, but it is currently not approved for my use. If it's something that can be worked around in 4.5.1, that would be ideal. If not, I may have no choice but to slog through getting the newer version approved, assuming it doesn't exhibit the same behavior.

  • nmrao's avatar
    nmrao
    Champion Level 3
    8 years ago
    4.5.1 is very stable release and I believe it is widely being used.

    Can you show how you are steps are?
    Do you see the same issue if you run it from UI?
    Are you running Sequential or Parallel?
    How many such cases there which wait for so long?
    • jgoguen's avatar
      jgoguen
      Occasional Contributor
      8 years ago

      I'll enumerate the general flow of the tests to give you a better idea of what's happening. I have about 34 soap requests at the beginning that basically set up some services. At the end I have about 34 soap requests that tear down the services. In between I have groups of a few operations separated by delays of 13 minutes. In all, there are 37 of these groups, resulting in a test that will run for about 8 hours. Generally, the groups are just 2 requests that get executed in serial, but there are 6 groups of 34 parallel requests spaced evenly throughout the test that are basically checking status on the services.

       

      Like so:

       

      34 parallel setups

      20 second delay

      34 parallel starts

       

      ___  Following block pattern repeats 6X (with different requests)

      |   13 minute delay

      |   1 service operation request

      |   3 second delay

      |   1 service status request

      |  

      |   13 minute delay

      |   1 service operation request

      |   3 second delay

      |   1 service status request

      |  

      |   13 minute delay

      |   1 service operation request

      |   3 second delay

      |   1 service status request

      |  

      |   13 minute delay

      |   1 service operation request

      |   3 second delay

      |   1 service status request

      |  

      |   13 minute delay

      |   1 service operation request

      |   3 second delay

      |   1 service status request

      |  

      |   13 minute delay

      |   34 parallel service status requests

      ------ End block pattern

       

      34 parallel service tear downs

      • nmrao's avatar
        nmrao
        Champion Level 3
        8 years ago
        Thank you for the details, Would you mind to show the project structure?
  • jgoguen's avatar
    jgoguen
    Occasional Contributor
    8 years ago

    So, I've gone through several iterations rearranging and running tests, and I think I may have discovered a way to get my tests to run without hanging or crashing. My latest permutation breaks out any delay longer than 30 seconds to its own test suite. I've run several times without any SoapUi issues. I'm not sure if the problem happens when a test suite runs for too long or if it's because there are several long delays spread out over one test suite, but it did hang pretty reliably before I changed it to the current strategy. It's an interesting problem that I'd like to spend more time testing to find the specific combination that reproduces it, but SmartBear doesn't pay me enough for that. XD

    • omnibb's avatar
      omnibb
      Visitor
      6 years ago

      I have this problem in SoapUI 5.4.0, only in TestRunner. Everything works fine in SoapUI.

       

      The solution posted isn't suitable for my scenario. I have a loop within a single testSuite. In the loop data is pulled in from an Excel file using groovy, it's then put into into a database, there is a wait, and the data is retreived elsewhere. There are other testSuites in the project with Waits, with a maximum of 30 seconds. The SoapUI project has yet to complete execution, it will always hang on or shortly after one these waits.

       

      Disabling the Waits allows the project to run through, but obviously the tests fail as the data has not propogated. I have tried many things including adding a custom Timeout to every test step in the project. But I am defeated and will have to restructure the project now for use with testrunner.

       

      Has anyone since found other work arounds for this? Thanks.