DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34615>. 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: [EMAIL PROTECTED] 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("<html>\n<head>\n<title>Test Page</title>"); out.println(" <link rel=\"stylesheet\" href=\"/myapp/myapp?action=css\"></script>"); out.println("</head>\n<body>\n <h2>Test Page</h2>\n</body>\n</html>"); } } 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
