tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Riyad Kalla <>
Subject Tomcat creating new sessions between Servlet->JSP request dispatch under load
Date Tue, 26 Apr 2005 22:20:19 GMT
The subject is sort of a brain dump of what is going on, let me
explain what is happening:

ControllerServlet loads page content from DB and stores it in the
session under a well known key, then it uses a requestDispatcher to
send control to the appropriate JSP to render the content. So it looks
something like this:

ControllerServlet (Load DB content, Store in Session) -> (REQUEST
DISPATCH) -> JSP page (render results)

Server Hardware:
Quad 2.4ghz XEON
2GB Ram
Gentoo Linux (all stable), 2.6.9 Kernel
Tomcat 5.0.28/JDK 1.4.2_08
(AND also tested on)
Tomcat 5.5.9/JDK1.5.2_02

Description of Problem:
When we recieve 8 or more concurrent requests, what happens is when
the JSP page goes to display the DB content that was loaded for it by
the ControllerServlet, the content variable is actually null and the
page throws a NPE. As we up the requests (15 concurrent, 20
concurrent, all the way to 40 concurrent) the number of failed clients
hovers around 1/2, sometimes more, sometimes less. It is seemingly
random which ones fail and how many, but there are definately pages

The strangest part of all this is that I thought something might be
occuring with the Sessions, because the last lines of code in the
ControllerServlet look like this:
session.setAttribute(Constants.DTO_PAGE, pageDTO);
requestDispatcher.forward(request, response);

and the first line of the JSP page looks like this:
PageDTO pageDTO = (PageDTO)session.getAttribute(Constants.DTO_PAGE);
<NPE thrown here from pageDTO being null sometimes>

so what I did was print out the session.hashCode() value in the
ControllerServlet right before the requestDispatch call, and then I
printed it out in the JSP page on the condition that pageDTO was null,
and oddly (I think) enough, in every case where pageDTO was null, the
hashCode of the session I printed out from the JSP page, was a totally
new Session that had no matching hashCode value printed out from the

So it *seems* that under heavy load Tomcat is creating entirely new
Sessions for the client between the ControllerServlet and then the
dispatch to the JSP page, so by the time the JSP page loads, the old
Session that had it's DB information in it, has been toasted for some

What confuses me the most, is that I'm using a requestDispatcher to do
this transfer, not a sendRedirect, so I don't understand how or why a
new Session would be created, there is no chance for the client to
turn around and re-request information as I understand the
requestDispatcher's behavior.

Any ideas or comments on how I can approach debugging this issue?
There is limited code to analyze for bugs as this seems to magically
happen between the last lines of Servlet and first lines of the JSP
page, but i might be missing some fundamental design of Web apps, I'd
appreciate any suggestions.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message