Contributions
Mockservice concurrency problem
In SoapUI 5.0.0 (Free) the behaviour of a mockservice returning a SEQUENCE of messages is not consistent. In a loadtest with multiple threads some messages are delivered more than once, other messages are skipped. This happens in about 4% of the cases. An example from the logs when using 5.0.0: 2014-10-23 11:28:29,793 INFO [SoapUIMockServiceRunner] Handled request 62; [get_user] with [User 75] in [67ms] at [2014-10-23 11:28:29.593] 2014-10-23 11:28:29,808 INFO [SoapUIMockServiceRunner] Handled request 94; [get_user] with [User 75] in [93ms] at [2014-10-23 11:28:29.586] Message [User 75] was used twice, [User 76] was never delivered. As a workaround I run the mockservice from the commandline in SoapUI 4.6.4.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions783Views0likes0CommentsLoadtest with mockservice fails when threads >= 196
I created a simple mockService to do some subsystem loadtesting. The service works fine, but when the number of threads reaches or passes precisely 196 in a loadtest I will only get java.net.SocketTimeoutException: Read timed out. The system has plenty of memory and processing power left. It makes no difference if it's in a testcase of its own or in a case with more steps. I also tried introducing some delays, but this has no effect either.12 years agoPlace ReadyAPI QuestionsReadyAPI Questions893Views0likes0CommentsRe: Session/Cookie handling bug in soapUI 4.5.1
I observed also HTTP session is no longer properly maintained in recent versions of soapUI. I tested with 4.5.1 and the latest nightly build, all with the same results. There seems to be one HTTP session shared by all threads. I created a testcase (attachment) to demonstrate this behavior. I checked "Maintain HTTPS Session". I created a webservice that creates a session. Subsequent calls report the number of times this particular session has been used. This public service is (temporary) available at http://d4cca2c7.cm-2.dynamic.ziggo.nl:8 ... ount_calls. If you call it in a browser the behavior can be checked by using <F5>. I call this service twice in the testcase: the first time the times_uses should be 0, the second time is should be 1. The single testcase is successful, but the loadtest with multiple threads fails big time! The same session cookie is used for all calls by all threads. A small improvement can be made by dropping the cookie in the first test step, but I don't think that should be necessary.12 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.2KViews0likes0Comments