When exactly is the HttpSession expired (starts being eligible for destroying - not necessarily destroyed yet)?

Question

I would like to know when exactly an HttpSession would be expired (not the same as destroyed)?

I am trying to figure out if session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) will give me the exact time in milliseconds of session expiry each time a request comes with the same session id!

From the javadocs:

long getLastAccessedTime()

  Returns the last time the client sent a request associated with this session, as the number of milliseconds since midnight January 1, 1970 GMT, and marked by the time the container received the request.

int getMaxInactiveInterval()

  Returns the maximum time interval, in seconds, that the servlet container will keep this session open between client accesses.

Lets say we have the following:
Treq1 - the time the container received the 1st request (HttpSession.lastAccessedTime)
Tresp1 - the time the container sends the 1st response
Preq1 - the time period between Treq1 and Tresp1 (the time period that the server processes the 1st request
Treq2 - the time the container received the 2nd request (HttpSession.lastAccessedTime)
Preq1req2 - the time period between Treq1 and Treq2 (the time between requests entering the container)
Presp1req2 - the time period between Tresp1 and Treq2 (the time between the 1st response exiting the container and the 2nd request entering the container)

So now, when does the server calculate the session as expired? When:
1. Treq1 + maxInactiveInterval < Treq1 + Preq1req2 => maxInactiveInterval < Preq1req2
2. Tresp1 + maxInactiveInterval < Tresp1 + Presp1req2 => maxInactiveInterval < Presp1req2

This part, the servlet container will keep this session open between client accesses is a bit confusing. Does it mean between requests entering the container or between response exiting and requests entering?

On a side note, I know that the session might not be destroyed at the exact time of expiry, but I don't know yet if it is destroyed before any request processing logic occurs in the container. I am referring to the request that holds an expired session id.

Kind Regards,
Despot

Why does it matter? The time of a request is typically a few milliseconds. The session timeout is typically 30 minutes. Does it matter if it's 30.000 or 30.002? What is your end goal? Anyway, the answer is in the question: *and marked by the time the container received the request* — JB Nizet, Jan 04 '13 at 09:54
It matters, since I want to know at the client exactly what time the session will be expired. "the answer is in the question: and marked by the time the container received the request" this might only refer to the lastAccessedTime. Are you sure that the expiration time is going to be session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) (1. case)? Is there any source out there that could confirm it? Thanks for the comment! — despot, Jan 04 '13 at 10:11
And you want to have that precise to the millisecond? Does the end-user care if it's in 30 minutes or in 30 minutes and 8 milliseconds? Anyway, the session won't be destroyed at that time, since the container typically uses a background thread that destroys expired sessions every minute or so. — JB Nizet, Jan 04 '13 at 10:19
Firstly, the processing on the server could take more than 8 milliseconds, and secondly, I need to make sure that I am not sending a request at a certain endpoint with an expired session (and I want to maximize the time I send requests to this endpoint). "the session won't be destroyed at that time" I understand this(see the part "On a side note"). This doesn't answer the question of the server expiration time (not destroying time). I want to understand first, how exactly the server calculates the expiration time. — despot, Jan 04 '13 at 10:53
The way to be sure you aren't sending a request to a timed-out session is to *send* it and deal with the resulting error condition(s). Which you have to do anyway. Any predictive approach is bound to fail sooner or later, and amounts to nothing more than fortune-telling in reality. — user207421, Jan 04 '13 at 11:33
"...and deal with the resulting error condition(s)" I am doing that. But the logic on the client side dictates that it needs to know if the session is expired at the server (or in other words at what point will it be eligible for destroying). In short, I am sending a request on endpoint1, getting a JSESSIONID with expiry date; sending requests to endpoint2 until JSESSIONID expires. I just need to make sure that requests I send to endpoint2 don't have their cookie expired yet. I'm dealing with errors but need to be sure how the server calculates the time of expiry. — despot, Jan 04 '13 at 13:48

score 11 · Accepted Answer · answered Jan 04 '13 at 15:26

The session mechanism is part of the Servlet specification, which mandates:

In the HTTP protocol, there is no explicit termination signal when a client is no longer active. This means that the only mechanism that can be used to indicate when a client is no longer active is a time out period.

The default time out period for sessions is defined by the servlet container and can be obtained via the getMaxInactiveInterval method of the HttpSession interface. This time out can be changed by the Developer using the setMaxInactiveInterval method of the HttpSession interface. The time out periods used by these methods are defined in seconds. By definition, if the time out period for a session is set to -1, the session will never expire. The session invalidation will not take effect until all servlets using that session have exited the service method. Once the session invalidation is initiated, a new request must not be able to see that session.

The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed before the current request. The session is considered to be accessed when a request that is part of the session is first handled by the servlet container.

It is probably safe to assume that the "inactive interval" starts with the "lastAccessedTime".

ok, so session expiry time should be calculated with session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000), and the case 1. is the correct one?! — despot, Jan 08 '13 at 15:52
As the last part of the citiation contains "...determine the last time the session was accessed _before the current request_." means to me, that this time is not the current request, but the request before that. So to determine the session end time you have to add the current time at the beginning of the request to the maxInactiveInterval, as in @Subin s answer. — cyberbrain, Mar 02 '17 at 13:14

score 3 · Answer 2 · answered Jan 04 '13 at 09:53

3

I am trying to figure out if session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) will give me the exact time in milliseconds of session expiry each time a request comes with the same session id!

since you can access session object only in a request thread I am assuming you are having above code in a servlet for informing client(browser) on what time he can take before his next click, may be a timeout counter.

I assume System.currentTimeMillis() + (session.getMaxInactiveInterval() * 1000) will be more accurate in that case.

answered Jan 04 '13 at 09:53

Subin Sebastian

10,870
3
37
42

"for informing client(browser)" precisely. "I assume System.currentTimeMillis() + (session.getMaxInactiveInterval() * 1000)" so you are assuming that it is the 2. case?! Any source so we can be sure on this? Thanks for your answer! – despot Jan 04 '13 at 10:13
if you want to display it in human readable format you can use: SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"); Date resultdate = new Date(timeInMs); System.out.println("Date in HRF: " + sdf.format(resultdate)); – Enrique San Martín Nov 08 '17 at 15:25

samm · Answer 3 · 2017-11-15T11:05:59.897

source?

I traced requests twice using "org.springframework.boot:spring-boot-starter-web:1.5.6.RELEASE" spring and concluded:

In your service handler (doGet, doXX, or Controller methods), the expiration time is going to be session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) (2. case)

Duration:        |<---------- Preq1req2 ---------->|
Duration:        |           |<---- Presp1req2 --->|
Time    :      Treq1       Tresp1                Treq2      Tresp2
Action  : req1-->|--service--|-->resp1 ...  req2-->|--service--|-->resp2
Duration:        |<- Preq1 ->|                     |<- Preq2 ->|
                 |           |                                 | 
Set :       creationTime     |                                 |   
          lastAccessedTime   |                                 |            
                      lastAccessedTime                  lastAccessedTime

When lastAccessedTime is updated after service:

Code snippet from C:/Users/ssfang/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/8.5.16/tomcat-embed-core-8.5.16-sources.jar

package org.apache.catalina.session;
public class StandardSession implements HttpSession, Session, Serializable {
    /** The time this session was created, in milliseconds since midnight, January 1, 1970 GMT. */
    protected long creationTime = 0L;

    /**
     * We are currently processing a session expiration, so bypass
     * certain IllegalStateException tests.  NOTE:  This value is not
     * included in the serialized version of this object.
     */
    protected transient volatile boolean expiring = false;

    /** The last accessed time for this Session. */
    protected volatile long lastAccessedTime = creationTime;

    /** The session event listeners for this Session. */
    protected transient ArrayList<SessionListener> listeners = new ArrayList<>();

    /** Flag indicating whether this session is valid or not. */
    protected volatile boolean isValid = false;

    /** The current accessed time for this session. */
    protected volatile long thisAccessedTime = creationTime;


    /** The access count for this session. */
    protected transient AtomicInteger accessCount = null;

    /**
     * The maximum time interval, in seconds, between client requests before the servlet container may
     * invalidate this session.  A negative time indicates that the session should never time out.
     */
    protected volatile int maxInactiveInterval = -1;

    /**
     * Return the idle time from last client access time without invalidation check
     * @see #getIdleTime()
     */
    @Override
    public long getIdleTimeInternal() {
        long timeNow = System.currentTimeMillis();
        long timeIdle;
        if (LAST_ACCESS_AT_START) {
            timeIdle = timeNow - lastAccessedTime;
        } else {
            timeIdle = timeNow - thisAccessedTime;
        }
        return timeIdle;
    }

    /**
     * Set the creation time for this session.  This method is called by the
     * Manager when an existing Session instance is reused.
     *
     * @param time The new creation time
     */
    @Override
    public void setCreationTime(long time) {
        this.creationTime = time;
        this.lastAccessedTime = time;
        this.thisAccessedTime = time;
    }

    /** Return the <code>isValid</code> flag for this session. */
    @Override
    public boolean isValid() {
        if (!this.isValid) {
            return false;
        }
        if (this.expiring) {
            return true;
        }
        if (ACTIVITY_CHECK && accessCount.get() > 0) {
            return true;
        }
        if (maxInactiveInterval > 0) {
            int timeIdle = (int) (getIdleTimeInternal() / 1000L);
            if (timeIdle >= maxInactiveInterval) {
                expire(true);
            }
        }
        return this.isValid;
    }
}

Check whether the session is valid before getting the session

A background thread to scan all sessions whether have expired.

When exactly is the HttpSession expired (starts being eligible for destroying - not necessarily destroyed yet)?

3 Answers3