Thread Safety issues in Mock Service as WAR
I am working with a client and was hoping to propose the use of SoapUI v3.6.1 mock services as a viable alternative to hand coded mock services. They use these mock services to provide stubs for back...
Forum Discussion
Ole thanks for replying.
We tested both the commandline mockrunner and from within SOAP-UI and neither exhibited the problem. Our tests ran fine. Unfortunately that is not a viable solution for us because we need to co-deploy the mock service with the middleware code we are developing in a servlet container as a war.
The thread safety issue actually is in the com.eviware.soapui.mockaswar.MockAsWarServlet code. In our case we most often see problems when the results.remove(0) call happens (however I suspect there may be some other issues given the prevalence of this type of instance member variable usage throughout the servlet).
Here's the problem code block from the MockAsWarServlet:
The issue here is that "results" is a class level variable, and since the servlet container creates only a single instance of the servlet, all threads that call this servlet are accessing the same "results" object. The Results object is an Apache Commons TreeList class which is not thread safe without the developer doing explicit synchronization.
I suspect the alternative is for us to write a simpler version of the MockAsWarServlet without the extra features you provide in your implementation that causes the thread safety issues.
Again thanks for looking in to this issue. In general I'm quite happy with Soap-UI, but this is definitely a show stopper for our intended use.
We tested both the commandline mockrunner and from within SOAP-UI and neither exhibited the problem. Our tests ran fine. Unfortunately that is not a viable solution for us because we need to co-deploy the mock service with the middleware code we are developing in a servlet container as a war.
The thread safety issue actually is in the com.eviware.soapui.mockaswar.MockAsWarServlet code. In our case we most often see problems when the results.remove(0) call happens (however I suspect there may be some other issues given the prevalence of this type of instance member variable usage throughout the servlet).
Here's the problem code block from the MockAsWarServlet:
if( request.getPathInfo().equals( mockRunner.getMockService().getPath() ) )
{
MockResult result = mockRunner.dispatchRequest( request, response );
while( maxResults > 0 && results.size() > maxResults )
{
results.remove( 0 );
}
if( result != null )
{
results.add( result );
}
return;
}
The issue here is that "results" is a class level variable, and since the servlet container creates only a single instance of the servlet, all threads that call this servlet are accessing the same "results" object. The Results object is an Apache Commons TreeList class which is not thread safe without the developer doing explicit synchronization.
I suspect the alternative is for us to write a simpler version of the MockAsWarServlet without the extra features you provide in your implementation that causes the thread safety issues.
Again thanks for looking in to this issue. In general I'm quite happy with Soap-UI, but this is definitely a show stopper for our intended use.