Answer included in your text, and at the end.
Anthony Presley wrote:
>[...] and I'm having a lot of errors, which
>scale based on the number of users. For instance, assuming I have
>around 10 people working on the system, I will have no errors. As that
>number scales, it becomes a huge problem, and lots of error's start
>showing up. I've tracked down and squashed most of the DB errors, but
>am left with the following quandry:
>
>
It smells like a concurrency problem.
>I'm not storing any data in the session, and use forward() ... a lot.
>When the following code executes, and I only open one request (ie, I
>click on the link to open a new window which fetches a servlet
>response), it works flawlessly. When I click more than once, I start
>getting forward() errors.
>
>
Smell is getting intense ;-)
>Here's some code snippets:
>
>
[... reduced to a minimum, but the problem still there ...]
> protected void forward(String s) {
> ServletConfig sc = null;
> ServletContext sContext = null;
> RequestDispatcher rd = null;
>
> sc = this.getServletConfig();
> sContext = sc.getServletContext();
> rd = sContext.getRequestDispatcher(s);
> rd.forward(req, res);
>
>
Hey! Where are you getting "req" and "res" from?!! My guess at the end.
>3. I've bumped the response buffer (in the servlet) from 8K to 75K
>(75000), which reduces the errors, but they are still present. Is there
>a GOOD way to estimate the amount needed?
>
>
No need to increase anything. It might alleviate the problem or even
improve performance (??), but not solve anything.
>4. Using DBCP 1.0 .... using the latest DBCP (1.1?), seems to reduce
>the errors further (1 in 10, approx). I've rewritten the code to ensure
>that connections are being opened / closed locally, and quickly. Timing
>it shows that the DB connection is pulled from the pool for about 2300
>milli, and the JSP runs for about 2 milli to display.
>
>
Same here. The shorter your DB connections are open, the better, but
this will not solve your problem.
>I'm not 100% sure yet if the problem persists in the JSP (using a simple
>JSP and simple servlet does not cause these problems, however, the
>greater the complexity, the higher the likelihood of getting these
>errors .... which baffle's me, because rerequesting it shows up fine,
>with nothing in the logs) or the servlet.
>
>
But the greater the complexity, the greater your chances to get two
users using your servlet concurrently.
>Anyone seen this before? I'm about at my wits end. Been refactoring
>for a week now, and still it persists.
>
>
Yes. I found it to be a very common mistake. Now you know where the
problem lies, you probably already thought of a solution specific to
your case.
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling "forward(s)" for a request once req and res have been
overwritten by another request.
Just in case my English is too bad, and so that the archive is useful
for people searching it:
- NEVER use object attributes in Servlets, as a rule of thumb.
- ALWAYS use local variables instead.
If you really cannot follow the above, then:
- Make sure that you need ONLY ONE INSTANCE of the object stored in that
attribute.
- One instance for: all concurrent users, and all successive requests.
- Make sure that this instance is THREAD SAFE.
- A typical example of this is the use of a logger.
- Another example are STATIC attributes, which are, in general, less
error-prone in this context.
If you really cannot follow any of the above, there is still one solution:
- Make sure your servlet "implements SingleThreadModel". This will
ensure a different instance is used for all concurrent requests, or that
no concurrent requests will occur.
Hope that helps.
Antonio Fiol
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
