tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol BonnĂ­n <>
Subject Re: response.reset() and forward() ... problematic? DBCP related?
Date Thu, 11 Dec 2003 06:49:06 GMT
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 
- 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:
For additional commands, e-mail:

View raw message