Forum Discussion
RFloyd2000
14 years agoOccasional Contributor
Unfortunately, closing the connection after each request does not produce the same behavior as soapUI either.
My test case is a sequence of HTTP GETs. Closing the connection after each request causes each HTTP GET to have it's own TCP port as if it were a separate connection.
It must be somehow coded differently within soapUI versus loadUI. The soapUI has the desired behavior... all the HTTP GETs that are part of the testSuite use the same connection (ie IP/PORT). This behavior gets changed once exported to loadUI. It appears that soapUIRunner tries to be "conservative" and squeeze as many threads as possible into the same IP/PORT. So if the socket is "busy", it moves to another TCP port.
Any ideas of what else may help to resolve this?
My test case is a sequence of HTTP GETs. Closing the connection after each request causes each HTTP GET to have it's own TCP port as if it were a separate connection.
It must be somehow coded differently within soapUI versus loadUI. The soapUI has the desired behavior... all the HTTP GETs that are part of the testSuite use the same connection (ie IP/PORT). This behavior gets changed once exported to loadUI. It appears that soapUIRunner tries to be "conservative" and squeeze as many threads as possible into the same IP/PORT. So if the socket is "busy", it moves to another TCP port.
Any ideas of what else may help to resolve this?