View source for JBossWeb/Tomcat HTTP Session Implementation Details

=External=

* How does JBoss EAP manage sessions in distribution mode? https://access.redhat.com/solutions/2482211

=Internal=

* [[HTTP_Session#Session_Implementation_Details|HTTP Session]]

=Relevance=

* EAP 6.4.6
* JBoss AS 5.1.2

=Subjects=

<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Web Application Monitoring in WildFly#Active_HTTP_Session_Count|Active HTTP Session Count]]
</blockquote>

=Clustered Session Diagram=

[[Image:JBoss7_HTTP_Session_Replication_Architecture.png]]

=Lifecycle=

Each <tt>org.apache.catalina.connector.Request</tt> maintains a direct reference to the active <tt>Session</tt> instance the request belongs to. The reference can be <tt>null</tt>.

The repository of sessions for a specific application (context) is an instance of <tt>org.apache.catalina.Manager</tt>. The manager is referred to from the <tt>StandardContext</tt> via the <tt>manager</tt> reference.
* If the application is not clustered, the <tt>Manager</tt> implementation is an <tt>org.apache.catalina.session.StandardManager</tt>.
* If the application is clustered, the <tt>Manager</tt> implementation is an <tt>org.jboss.as.web.session.DistributableSessionManager</tt>.

Sessions are not created automatically by the Tomcat machinery, unless we invoke <tt>HttpServletRequest.getSession()</tt> (which is equivalent with <tt>HttpServletRequest.getSession(true)</tt>) or <tt>org.apache.catalina.connector.Request.getSessionInternal()</tt>.

When <tt>HttpServletRequest.getSession()</tt> is invoked, the following happen:
* The <tt>Manager</tt> instance is obtained from the <tt>StandardContext</tt> associated with the request.
* <tt>Manager.findSession(sessionId)</tt> is messaged on the <tt>Manager</tt> instance.
* The <tt>Session</tt> is looked up in the <tt>sessions</tt> map by its session ID. This applies to both non-clustered and clustered sessions.

==Session Found==

If the session is found, <tt>access()</tt> method is invoked on it.

If the session is not clustered, it is then simply returned. 

If the session is clustered (an <tt>org.jboss.as.web.session.ClusteredSession</tt> implementation), the node attempt to acquire ownership, by invoking <tt>acquireSessionOwnership()</tt> method. For more details on session ownership, see [[#Session_Ownership_and_Locking|Session Ownership and Locking]].

==Session Not Found==

If no session is found, and <tt>org.apache.catalina.connector.Request.SESSION_ID_CHECK</tt> is true, the request tries to find the session with the ID equals to requestedSessionId among the Host's children.

If no session is found, the <tt>Manager</tt> instance is messaged to <tt>createSession(sessionId)</tt>.

==Common==

Once the session is created by the manager (and its id generated), or it is retrieved, the request then sets a "session" cookie on Response "Set-Cookie" "JSESSIONID=FFB6...56; Path=/mycontext". The internal implementation of the cookie is <tt>TomcatCookie</tt>.

=Clustered Session Access and Replication=

The write entry point is <tt>org.jboss.as.web.session.ClusteredSession.setAttribute(...)</tt>

The write access consists in the following sequence:

* The state of the session is checked.
* The write arguments are checked to make sure they're are Serializable.
* The "sessionAttributesDirty" is set to <tt>true</tt>.
* The change is applied by firing <tt>HttpSessionBindingEvent</tt> instances to <tt>HttpSessionAttributeListener</tt> implementations.

This is where the interaction with the session ends. The replication is triggered either by the <tt>ClusteredSessionValve</tt> or the <tt>InstantSnapshotManager</tt>. See below:

==Synchronous Replication==

<tt>ClusteredSessionValve</tt> triggers replication by messaging <tt>org.jboss.as.web.session.InstantSnapshotManager</tt>.

==Asynchronous Replication==

Asynchronous replication is driven by <tt>org.jboss.as.web.session.ClusteredSessionValve</tt> and the [[HTTP_Session_Replication#snapshot-mode|snapshot-mode]] configuration.

If the snapshot-mode is INSTANT, after the servlet invocation, the valve asks the associated snapshot manager to "snapshot" the session on the same HTTP/AJP thread. The <tt>org.jboss.as.web.session.InstantSnapshotManager</tt> messages <tt>DistributableSessionManager</tt> to store the session. The <tt>DistributableSessionManager</tt> messages the <tt>BatchingManager</tt> and the snapshot is written in the cache.

If the snapshot-mode is INTERVAL, the replication is done periodically on a separated thread.

For more details on the concepts around synchronous/asynchronous replication see:

<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[HTTP_Session_Replication#Synchronous_and_Asynchronous_Replication|Synchronous vs. Asynchronous Replication]]
</blockquote>

==Common==

In both cases, <tt>org.jboss.as.web.session.InstantSnapshotManager</tt> messages <tt>org.jboss.as.web.session.DistributableSessionManager</tt> instance by invoking <tt>storeSession(...)</tt>.

=SessionID Generation=

SessionID is generated by <tt>org.apache.catalina.session.ManagerBase.generateSessionId()</tt>.

<pre>
/**
 * Generate and return a new session identifier.
 */
protected String generateSessionId(Random random) {
    byte[] bytes = new byte[sessionIdLength];
    random.nextBytes(bytes);
    // Encode the result
    char[] id = encode(bytes);
    String jvmRoute = getJvmRoute();
    if (appendJVMRoute() && jvmRoute != null) {
        StringBuilder buffer = new StringBuilder();
        buffer.append(id).append('.').append(jvmRoute);
        return buffer.toString();
    } else {
        return String.valueOf(id);
    }
}
</pre>

=Session Counter=

Maintained by the <tt>sessionCounter</tt> variable of the <tt>StandardManager</tt> instance of the web application.

=Session Ownership and Locking=

Before a node tries to use a session, it first tries to obtain the session ownership via locking, which translates into a RPC call across the cluster. That is why is almost a good idea to configure session stickiness. For more details on general concepts related to session replication and ownership, see [[HTTP_Session_Replication#Session_Stickiness_and_Session_Ownership|HTTP Session Replication - Session Ownership and Stickiness]].

The session ownership is acquired by the <tt>DistributedCacheManager</tt> instance from the lock manager (<tt>DistributedLockManager</tt> instance). The result of the lock acquisition attempt could be:
* NEW_LOCK
* ALREADY_HELD
* ACQUIRED_FROM_CLUSTER

The default timeout when the lock manager is trying to lock is 15,000 ms (15 seconds).

=Interaction with the Underlying Cache=

The session is initially retrieved from the underlying cache by getting a value associated with the session ID (example: "e7H9cWGDBFoM-KjyKpFug+uu"). The result is an <tt>org.infinispan.container.entries.ImmortalCacheEntry</tt> instance. The cache entry's key is the session ID, and the value is a map:

[[Image:ImmortalCacheEntry.png]]

==TRACE Logging==

<pre>
<logger category="org.infinispan.client.hotrod.impl.RemoteCacheImpl">
    <level name="TRACE"/>
</logger>
</pre>

Writing:
<pre>
18:14:03,571 TRACE [org.infinispan.client.hotrod.impl.RemoteCacheImpl] (http-/127.0.0.1:8480-3) About to add (K,V): (pfo9WAKHFM08w1LH-Ejxr+Yv, ImmortalCacheEntry{key=pfo9WAKHFM08w1LH-Ejxr+Yv, value=ImmortalCacheValue {value=AtomicHashMap}}) lifespanSecs:0, maxIdleSecs:0
</pre>

===HTTP Session Management Layer Tracing===

{{Internal|JBoss HTTP Session Troubleshooting|JBoss HTTP Session Troubleshooting}}

==Who's Storing?==

<tt>org.infinispan.interceptors.CacheStoreInterceptor</tt>. It creates an <tt>ImmortalCacheEntry</tt>, see below:

==Stored Data Structure==

An <tt>ImmortalCacheEntry</tt> instance whose value is a Map:
* byte (0) - Integer (version?)
* byte (1) - Long (timestamp?)
* byte (2)  - <tt>org.jboss.as.clustering.web.DistributableSessionMetadata</tt> instance.
** String id
** long creationTime
** int maxIntactiveInterval
** boolean isNew
** boolean isValid
* byte (3) - <tt>org.jboss.as.clustering.SimpleMarshalledValue</tt> instance - representing the attribute being written.

==Session Lifecycle==

Session creation.

<pre>
get("WXVsiy0ZeTzLxXOo59WGvm4l")
get("WXVsiy0ZeTzLxXOo59WGvm4l")
get("UOU5nFssi1ENLGUdKUX+AO4x") 
get("UOU5nFssi1ENLGUdKUX+AO4x")
put("WXVsiy0ZeTzLxXOo59WGvm4l", immortalCacheEntry)
immortalCacheEntry:
key: "WXVsiy0ZeTzLxXOo59WGvm4l"
value: Map
          (byte)0 -> Integer(1)
          (byte)1 -> Long(...)
          (byte)2 -> DistributableSessionMetadata instance
</pre>

Write attribute 1

write(TESTKEY1,TESTVALUE1)

<pre>
put("WXVsiy0ZeTzLxXOo59WGvm4l", ImmortalCacheEntry instance)
immortalCacheEntry:
key: "WXVsiy0ZeTzLxXOo59WGvm4l"
value: Map
          (byte)0 -> Integer(2)
          (byte)1 -> Long(...)
          (byte)2 -> DistributableSessionMetadata instance
          "TESTKEY1" -> "TESTVALUE1"
</pre>

Read attribute 1

No cache access

Write attribute 2

<pre>
put("WXVsiy0ZeTzLxXOo59WGvm4l", ImmortalCacheEntry instance)
immortalCacheEntry:
key: "WXVsiy0ZeTzLxXOo59WGvm4l"
value: Map
          (byte)0 -> Integer(2)
          (byte)1 -> Long(...)
          (byte)2 -> DistributableSessionMetadata instance
          "TESTKEY1" -> "TESTVALUE1"
          "TESTKEY2" -> "TESTVALUE2"
</pre>

Read attribute 2

No cache access

…

Write attribute n

Read attribute n

Loop 

Invalidate the session and remove it from cache

<pre>
remove("WXVsiy0ZeTzLxXOo59WGvm4l")
</pre>

Expiration?