LoadTest threads are getting stuck for me
Greetings
I've been working with SoapUI for a little more than a year, can't call myself a pro and I could really use some adcive on an issue I've stumbled upon.
I've created this TestCase that automatically generates JMS requests that are sent to our JMS gateway that processes the requests as they come. The aim of this is to generate a big enough load on our interfaces that would simulate sending these requests in batches in real environments. To do this, I execute the TestCase in the LoadTest interface in SoapUI, because it gives me the opportunity to create more threads/instances of the TestCase at a time.
All this went well until I tried to create a load of several threads ( tens of thousands of JMS requests altogether) in our testing environment. Almost every time I executed such loadTest, one or more threads stopped being executed at pretty much random times. I can not find out why this is happening, the loadTest does not log every single TestStep result, so I added some manual logging wherever it was possible ( Groovy script test steps), but that only gave me a slight idea of when a thread stopped, not the reason why it did so.
I've tried executing the TestSuite the old fashioned way ( not using a loadtest and thus only a single thread was executed) and the test ended successfully, so I don't think the script could be at fault.
I'm pretty sure it's not a matter of any conflicts between threads and their data, all threads should operate with an incremented separate set of data based on their thread index.
I've tried to execute the load test using a LoadTestRunner, even as the threads stopped working ( I have a debugging message at the end of every TC, which was not displayed when these threads got "stuck") the loadTestRunner was still running, really don't know what to think of this.
I've tried to execute the test in a way where the requests were directed to a dummy SOAP interface and no threads got stuck, so I guess this could be a matter of JMS communication. There is no response message for those JMS requests, but that was never a problem.
What I really miss is proper logging of all the low-level events that are happening when a loadTest is executed, so I could find out why the threads keep on getting stuck randomly. Sometimes, a thread ends up posting a JMS request, but there is no such event recorded on the server side. At other times, I can't tell where exactly the process stopped.
Please, if some of you guys have a tip for me, I would very much appreciate it if you'd help me on this, I've been browsing the web and forums for weeks, but could not find what would be the cause of this issue. I'm willing to share the TestCase script if someone's interested. I'm not using the Pro version yet, but I might do so in the future if things go well.
Sorry for the wall of text, just wanted to be thorough on this, have a nice day
I've been working with SoapUI for a little more than a year, can't call myself a pro and I could really use some adcive on an issue I've stumbled upon.
I've created this TestCase that automatically generates JMS requests that are sent to our JMS gateway that processes the requests as they come. The aim of this is to generate a big enough load on our interfaces that would simulate sending these requests in batches in real environments. To do this, I execute the TestCase in the LoadTest interface in SoapUI, because it gives me the opportunity to create more threads/instances of the TestCase at a time.
All this went well until I tried to create a load of several threads ( tens of thousands of JMS requests altogether) in our testing environment. Almost every time I executed such loadTest, one or more threads stopped being executed at pretty much random times. I can not find out why this is happening, the loadTest does not log every single TestStep result, so I added some manual logging wherever it was possible ( Groovy script test steps), but that only gave me a slight idea of when a thread stopped, not the reason why it did so.
I've tried executing the TestSuite the old fashioned way ( not using a loadtest and thus only a single thread was executed) and the test ended successfully, so I don't think the script could be at fault.
I'm pretty sure it's not a matter of any conflicts between threads and their data, all threads should operate with an incremented separate set of data based on their thread index.
I've tried to execute the load test using a LoadTestRunner, even as the threads stopped working ( I have a debugging message at the end of every TC, which was not displayed when these threads got "stuck") the loadTestRunner was still running, really don't know what to think of this.
I've tried to execute the test in a way where the requests were directed to a dummy SOAP interface and no threads got stuck, so I guess this could be a matter of JMS communication. There is no response message for those JMS requests, but that was never a problem.
What I really miss is proper logging of all the low-level events that are happening when a loadTest is executed, so I could find out why the threads keep on getting stuck randomly. Sometimes, a thread ends up posting a JMS request, but there is no such event recorded on the server side. At other times, I can't tell where exactly the process stopped.
Please, if some of you guys have a tip for me, I would very much appreciate it if you'd help me on this, I've been browsing the web and forums for weeks, but could not find what would be the cause of this issue. I'm willing to share the TestCase script if someone's interested. I'm not using the Pro version yet, but I might do so in the future if things go well.
Sorry for the wall of text, just wanted to be thorough on this, have a nice day