tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol BonnĂ­n <>
Subject Re: Servlet thread safety in Tomcat
Date Wed, 11 Feb 2004 20:24:27 GMT
Mike Curwen wrote:

>1) if by 'localized' you mean "I've moved the variables from outside the
>doGet()/doPost() methods, to inside those methods"... then this is why
>there is no 'data corruption' (due to multithreading issues), and it's
>why you don't require synchronized access to those variables.

You definitely do not need synchronized on local variables.

However, you DO need it if you use something "shared" among the 
requests. That is, outside the local scope.

>I will probably explain this perhaps not 100% correctly, but someone
>will catch me when I fall.. ;)
>A user request = one java thread.
>If more than one user requests something from your servlet, that means
>(potentially) more than one thread in your servlet methods.
>If one thread alters a variable outside of the doGet()/doPost() methods,
>then this modifies that variable for ALL threads, and thus, you get data
>confusion/corruption. It's a simple matter of scope.
>If the thread alters a variable within the method, then this variable is
>located in the method 'stack', and altering its value will only alter
>the data for that particular thread.  So it is literally impossible to
>'confuse' the data, if all of your variables are declared within the
>method. Again, a matter of scope.

No objection ;-)

>2) jmeter is an open-source web-testing tool.  Fairly simple, and works
>quite nicely. You can use it to load test an application, and can
>configure it to launch X threads simulatenously.  This would give you a
>fair chance of testing concurrency issues.  'X' will be solely
>determined by how much CPU and memory your testing box has.  Jmeter lets
>you slave multiple workstations to use as load generators, so X can
>become quite high (which is good).  
>You can also configure jmeter to check the results of a particular web
>request.  So for example, if a user submits a search to search.jsp with
>a certain set of search values... and you expect a result in your page
>of :
><p>your search returned <b>500</b> results</p> 
>Then you can actually test for this string in the returned webpage.  If
>the '500' is something else (say '450'), then you can begin to suspect
>concurrency issues.  (Because perhaps another of your simultaneous users
>used a different set of parameters, say ones that would produce '450').

It will not be easy to pinpoint concurrency problems using JMeter.

The procedure is roughly what Mike described. However, you will need to 
know your data very well, and possibly output some debugging info in 
your pages (maybe inside a HTML comment).

It will not be easy.

 From my experience, JMeter is really great for cases where border 
conditions make the server fail with a 500. You stress it, and it is 
more likely to fail. But detecting "slight" errors in the information 
contained in a page is a different business.

I wish I could give you an alternative, but I am afraid I know none.


Antonio Fiol

View raw message