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 = (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
