Return-Path: X-Original-To: apmail-tomcat-dev-archive@www.apache.org Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E24859B9D for ; Wed, 21 Sep 2011 18:06:57 +0000 (UTC) Received: (qmail 57985 invoked by uid 500); 21 Sep 2011 18:06:57 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 57915 invoked by uid 500); 21 Sep 2011 18:06:57 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 57905 invoked by uid 99); 21 Sep 2011 18:06:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Sep 2011 18:06:57 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of knst.kolinko@gmail.com designates 209.85.216.173 as permitted sender) Received: from [209.85.216.173] (HELO mail-qy0-f173.google.com) (209.85.216.173) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Sep 2011 18:06:49 +0000 Received: by qyc1 with SMTP id 1so17766181qyc.18 for ; Wed, 21 Sep 2011 11:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=CCWlggHrfFZ4cB7HSql+4ounGRUv32CvO6lbg9s9aLc=; b=EfLiMylSpR0oNWW/r0AedDPVuTwSt6XkkplmMwDnrhAiDWAdyhBQy72COH37TlsToN bj3Gao1NNFMAoA4qyuybS1u07ht6d+SiCzGyl/UIz4NuyXjOQUcQPW6aX490xK/ffjMD h2sbHTuepACL5kUWUSMGJ1p8vanZRFu990Hss= MIME-Version: 1.0 Received: by 10.52.26.226 with SMTP id o2mr894661vdg.474.1316628388066; Wed, 21 Sep 2011 11:06:28 -0700 (PDT) Received: by 10.52.111.40 with HTTP; Wed, 21 Sep 2011 11:06:28 -0700 (PDT) Date: Wed, 21 Sep 2011 22:06:28 +0400 Message-ID: Subject: Session.getLastAccessTime() ticking From: Konstantin Kolinko To: Tomcat Developers List Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi! I was reviewing the spec and the code with regards to the following issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=51812 Ch.7.6 of the Servlet specification (both 2.5 and 3.0 versions) says: "The session is considered to be accessed when a request that is part of the session is first handled by the servlet container." My understanding of the phrase is that a) Regardless of whether request.getSession(..) was called or not, if the request is part of a session the session access time must be updated. (Thus the use case reported in Bug 51812 cannot be implemented, unless you move your servlet into an independent webapp): regardless of how you try to avoid accessing the session in a servlet, the last accessed time should be "ticket" by any request that appears to belong to this session. b) The access time should be when request processing started, i.e. org.apache.coyote.Request#getStartTime() My findings in the current trunk: 1. Access time ticking is effectively done by Request.doGetSession(...). On first call if "(requestedSessionId != null)" it finds existing session and calls session.access(). There are several other places where access time is updated, but I think this is the main use case. As code fragment in issue 51812 shows, this method is always called when an Authenticator is configured in the webapp and does not have its cache disabled. (AccessLogValve can also access the session and thus tick its last access time -- from AccessLogValve$SessionIdElement or AccessLogValve$SessionAttributeElement, if it is configured to use those elements in its pattern). The first question that I have is that I do not see how last access is ticked if there is no explicit request for a session. I think it should be ticked regardless of whether getSession(..) has been called. 2. Access time in StandardSession is updated using System.currentTimeMillis(); The second question that I have is that it contradicts my "b)" point from above. I think it is against the spec. The third question is that there are a lot of places that call access(), and every such call updates thisAccessedTime in StandardSession. It looks like not all such calls are associated with an actual request, and strictly speaking they should not update the time. The second question can be demonstrated. Steps to reproduce: 1. Add the following line to catalina.properties: org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true 2. Add the following JSP page to the ROOT webapp and start Tomcat: sessionTest.jsp: [[[ <%@page session="false" import="java.util.*" contentType="text/plain;charset=UTF-8"%> <% out.println("Time 1: " + new Date()); Thread.sleep(2000); out.println("Time 2: " + new Date()); HttpSession session = request.getSession(true); Thread.sleep(2000); out.println("Time 3: " + new Date()); out.println("Last accessed: " + new Date(session.getLastAccessedTime())); %>]]] Open a new web browser and access the page three times. First access: Time 1: Wed Sep 21 21:36:25 MSD 2011 Time 2: Wed Sep 21 21:36:27 MSD 2011 Time 3: Wed Sep 21 21:36:29 MSD 2011 Last accessed: Wed Sep 21 21:36:27 MSD 2011 <- expected 21:36:25 Second access: Time 1: Wed Sep 21 21:36:32 MSD 2011 Time 2: Wed Sep 21 21:36:34 MSD 2011 Time 3: Wed Sep 21 21:36:36 MSD 2011 Last accessed: Wed Sep 21 21:36:27 MSD 2011 Third access: Time 1: Wed Sep 21 21:36:42 MSD 2011 Time 2: Wed Sep 21 21:36:44 MSD 2011 Time 3: Wed Sep 21 21:36:46 MSD 2011 Last accessed: Wed Sep 21 21:36:34 MSD 2011 <- expected 21:36:32 If I add the same jsp page into examples webapp, the behaviour becomes different: On first access: The same problem, System.currentTimeMillis() is used for a new session On third access: No problem: I see Time 1 from previous request, as expected. I think that is because examples webapp has protected pages and thus uses Authenticator. So if some webapp is used to test the difference in lastAccessedTime, it wouldn't see any problems if it uses Authenticator. Regarding the bug 51812, I think that it makes sense, but because of "a)" it cannot be implemented if Tomcat were strictly following the spec. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org