Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 77804 invoked from network); 26 Apr 2005 08:53:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Apr 2005 08:53:48 -0000 Received: (qmail 28781 invoked by uid 500); 26 Apr 2005 08:54:09 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 28260 invoked by uid 500); 26 Apr 2005 08:54:07 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 28242 invoked by uid 99); 26 Apr 2005 08:54:07 -0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from ajax-1.apache.org (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 26 Apr 2005 01:54:06 -0700 Received: by ajax.apache.org (Postfix, from userid 99) id 847942DE; Tue, 26 Apr 2005 10:53:27 +0200 (CEST) From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 34615] New: - Unecessary cluster replication of DeltaRequest AttributeInfo objects X-Bugzilla-Reason: AssignedTo Message-Id: <20050426085327.847942DE@ajax.apache.org> Date: Tue, 26 Apr 2005 10:53:27 +0200 (CEST) X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34615 Summary: Unecessary cluster replication of DeltaRequest AttributeInfo objects Product: Tomcat 5 Version: 5.0.30 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P3 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: chris@skipoles.co.uk Setup: Two Tomcat 5.0.30 servers arranged in a cluster with synchronous replication using multicast. Apache server using mod_jk2 to load balance between the two servers in a round-robin manner (no sticky sessions) Application: Initially discovered the problem while testing clustering of the wicket framework. However, problem can be replicated with small servlet (see bottom of description). This servlet handles two requests: 1) Request arrives to servlet (on serverA), which sets a session attribute and then outputs an HTML page. The HTML page contains a style sheet link with an href back to the same servlet. 2) Request for dynamically generated stylesheet arrives (on serverB). The session is not accessed and the css content is output. I added debug to org.apache.catalina.cluster.session.DeltaRequest and what I see happening is as follows: 1) Request to servlet arrives on serverA. Servlet sets a session attribute and returns the HTML content. 2) ServerA sends the delta request containing one AttributeInfo object to serverB and then resets its actions list. 3) ServerB receives the delta request containing the one AttributeInfo object 4) DeltaRequest.execute(DeltaSession) sets the attribute on the session. However, it DOESN'T remove the AttributeInfo object from the actions list. 5) Request to servlet arrives on serverB (to retrieve the css content). Servlet returns the css content but does not update the session. 6) DeltaManager.requestCompleted(String) is called on serverB. This checks if the actions list of the delta request is non-empty. 7) The actions list is non-empty because it contains the AttributeInfo object from the previous synchronization (4). Thus, the AttributeInfo object is sent back to serverA (which starts again at 3). The net result is that the same AttributeInfo object bounces back and forth between the two servers for each request that come in (regardless of whether the request alters the session or not). When the original page contains many dynamically generated images (retrieved concurrently by the browser) the externalization code finally falls in a heap with EOF and NPE problems due to the two machines trying to synchronize different copies of the same AttributeInfo object. The solution to the problem is to change the DeltaRequest.execute(DeltaSession) method to remove the AttributeInfo objects from the actions list after it has finished processing them: public synchronized void execute(DeltaSession session) { .... }//switch }//for >> reset(); session.endAccess(); } This appears to solve the problem. Example servlet (if anyone wants to test this out): public class MyAppServlet extends HttpServlet { protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException { final String action = request.getParameter("action"); if ( "css".equals(action) ) { response.setContentType("text/css"); PrintWriter out = response.getWriter(); out.println(".someStyle {\n padding: 5px;\n}"); } else { request.getSession().setAttribute("test", "value"); response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("\n\nTest Page"); out.println(" "); out.println("\n\n

Test Page

\n\n"); } } protected void doPost(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException { doGet(request, response); } } -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org