Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of rkalla@gmail.com designates
 64.233.184.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=fX/xECkV81xyXe4QUMQvMbJrv3bvu7iMGXLf3/CulogAAP1AVNuilkIA3HLU6W0Rdnz8O0sA48skMPwRYZ0kgKOBxOin//CRImEAtAllwksdQufbl2/sRMCwAi5eVLYGwSiYB7KQMAMUOuiVWOs8ktYKuUxXp1TLhu5ecFV1xxU=
Message-ID: <98ca874a05042615207c3e6a46@mail.gmail.com>
Date: Tue, 26 Apr 2005 15:20:19 -0700
From: Riyad Kalla <rkalla@gmail.com>
Reply-To: Riyad Kalla <rkalla@gmail.com>
To: tomcat-user@jakarta.apache.org
Subject: Tomcat creating new sessions between Servlet->JSP request dispatch
 under load
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The subject is sort of a brain dump of what is going on, let me
explain what is happening:

Setup:
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
failing.

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 =3D (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
ControllerServlet.

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
reason.

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.

Best,
Riyad

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org