Table of Contents
This chapter describes the structure, operation, and configuration of distributed session server that are used for session tracking in clustered environments.
Session servers are used to manage or back up client session data. They are especially useful when managing session data from multiple web servers and servlet engines in a clustered environment.
In JEUS 7, distributed session servers are used to manage session data.
Note
Prior to JEUS 7, central session server was used in general. Due to problems with centralized management of the system, only distributed session servers are used in JEUS 7.
Distributed session servers provide session clustering with enhanced scalability and safety. They enhance performance in a large scale clustered environment.
Distributed session servers have the same basic functionality as the central session server. In a clustered environment with many servlet engines, they allow sessions to persist even if a sequence of requests from the same client is not handled by the same servlet engine.
Distributed session servers mean that the managing agents of the sessions are distributed which provides high degree of scalability.
The following is a summary of distributed session server's characteristics.
-
It is possible to persist sessions in a clustered environment composed of many servlet engines.
-
Even if the servlet engine fails while processing a request, other servlet engines can continue to process the request without losing the session.
-
Scaling is easy because of the distributed protocol.
Distributed session servers use a distributed structure in which the servers that manage session objects are distributed to each servlet engine (web engine) or EJB engine.
When using distributed servers, a separate distributed session server exist in each engine of the cluster, and they provide continuous services by communicating with other distributed session servers.
The following diagram shows the session clustering structure with four web engines.
The arrows in the previous structure map represent possible socket connections between the distributed session servers. Instead of having all sockets always be connected to each other, they connect and maintain the connection only when they need to communicate with other engines in order to maintain a session.
The following diagram shows the internal structure of a distributed session server, which is a subcomponent of the web engine.
-
-
A module that oversees session management of the engine. It retrieves and manages both local and remote sessions.
-
The local web engine uses getSession to obtain session objects from the session manager.
To get a session, the web engine first tries to get a cached session from the memory, then a local storage session via getLocalStorageSession, and then a remote session via getRemoteSession.
-
If cached sessions are not used before the passivation timeout, they are saved to a file using passivateLocal and removed from the memory.
-
If a remote backup exists, modified sessions, are backed up using the backupSession method to the distributed session server that is designated as the backup server in the remote web engine.
The <backup-level> setting is used to determine if a session has been modified. A session is considered modified when a session operation, such as setAttribute and removeAttribute, is called while the <backup-level> is set to "all", the <backup-level> is set to "get" and a getter or setter method is called, or the <backup-level> is set to "set" and a setter method is called. For details about this configuration, refer to "2.7. Session Server Configuration".
-
When a remote web engine sends a migrate request, the session is returned from a cached session or the local storage in that order. The session in the local storage is deleted transferring the session ownership to the remote session server.
-
-
-
Backup Store manages the backup session objects that are periodically sent from another engine's distributed session server. This backup session object provides a replacement session if a failure occurs in the engine that contains the original session.
-
It receives the backup sessions from the remote web engine which is designated as a backup, and then saves and manages the backup session using backupSession and getBackupSession methods.
-
If the cached session is not used before the passivation timeout, it is saved using the passivateBackup method and then removed from the cache.
-
When the conditions are met for locally modified session objects, they are backed up to the distributed session server. Once the request is complete, the modified session objects are immediately backed up so that failover can be performed in case of a system failure.
-
If a migrate request is sent to the backup store from a remote web engine, the session is returned from the cache or local storage in that order.
-
-
-
Dynamic Remote Web Engine is a module that acts as a mediator when a specific operation is performed on a session in the remote web engine.
This engine operates by considering the dynamic nature of the environment. It selects an appropriate backup every time a server is added or removed. This is one of the major changes in JEUS 7 that is not related to environment configuration. The connection to the remote engine is verified through GMS instead of constant pinging to avoid sending repeated error messages for an ongoing error situation.
Note
JEUS 6 only recognizes the backup engine that is fixed in the configuration file. JEUS 7 is designed to allow dynamic changes to the remote engine.
-
-
-
The module that initially handles and distributes a session operation request from remote engines.
-
By default, distributed session servers use session routing. Session routing attaches the name of a specific session server to the session ID so that it knows which server contains the session data. Performance is enhanced when session routing is used.
Web servers that support session routing route requests to the web engine that contains the required session object. Session routing works in the same way for distributed session servers. For additional information, refer to "1.3.2. Session Tracking in Clustered Environments".
A session key is used for distributed session servers that use session routing.
The following example shows a session key being used in a web engine.
<SessionID>.<primary-engine-name> Example) XXX.domain1/server1
| Value | Description |
|---|---|
| XXX | Session ID. The actual session ID is a random string that is longer in length. |
| domain1/server1 | Routing information. A servlet engine named domain1 is used. |
Each engine is assigned a session routing ID for session routing that identifies the web engine when it connects to the web server. The session routing ID is automatically created according to its configuration. For the three web engines in [Figure 2.3], it is assumed that the session routing ID and back up server's session routing ID are assigned as follows:
-
Web engine (server1)
-
Session routing ID: domain1/server1
-
Session routing ID of the backup server: domain1/server2
-
-
Web engine (server2)
-
Session routing ID: domain1/server2
-
Session routing ID of the backup server: domain1/server3
-
-
Web engine (server3)
-
Session routing ID: domain1/server3
-
Session routing ID of the backup server: domain1/server1
-
The following diagram shows the failover structure of session tracking that uses the session routing ID assigned to each distributed session server.
The following describes the failover structure in [Figure 2.3].
-
The web server checks the session routing ID and attempts to send the request to web engine server1, but server1 has failed.
-
The web server arbitrarily selects a different web engine and sends the request. In this example, server3 is selected.
server3, which received the request from the web server, checks the session routing ID and determines that server1 contains the session object for the request, and that the backup exists in server2.
-
server3, which is a distributed session server, attempts to retrieve the session object by connecting to server1, but the request fails due to the failure of server1.
-
Because the request failed, server3 attempts to connect to the backup server, server2. Server2 returns the backup of the requested session object to server3.
-
Server3, which has successfully retrieved the session object, processes the client request and sends the response message to the client. A new session key is created and sent, the client's session key is modified, and future requests are forwarded to server3. When a new session key is created, only the session routing ID is changed.
Web servers cannot provide session routing in situations where the request cannot be sent because the web engine has failed or there is no connection to the target web engine.
The following describes [Figure 2.3] for distributed session servers where session routing is not used.
-
Without session routing, the session ID does not exist. The web server tries to send a request to an arbitrary web engine. In this example, web engine server1 is selected.
-
The web server detects that server1 has failed and selects another web engine, server3, and sends the request again.
-
Because server3 does not know the routing information of the session, it sends a request to the currently connected distributed session server, server1, but the attempt fails.
-
The distributed session server sends the request to server2, and server2 returns the session.
-
Server3, which received the session, sends the unmodified session key to the client. As a result, the next request may not be sent to server3 that contains the session.
Note
For explanation purposes, the routing information was written out as 'domain1/server1' but, this information is encoded during operation.
This section describes duplicate login prevention function that is newly added to distributed session servers.
Distributed session servers provide duplicate login prevention function that include the basic duplicate login management functions provided by applications.
Duplicate login prevention of distributed session servers prevents duplicate login using a single application ID. When the same ID is used to log into two different sessions, the existing session is removed to prevent duplicate login.
To prevent duplicate login, the login manager is configured similar to the existing central session server. A server that stores the login information is specified among the servers in the cluster, and a secondary server is configured to prepare for failure.
Duplicate login prevention can be configured for each application and login information is managed per application. The <use-jeus-login-manager> setting must be set to true in jeus-web-dd.xml.
The following is description of [Figure 2.4].
-
Client A using SessionA tries to log into Web EngineA with the ID, UserA.
-
Web EngineA registers the login information in the Login Manager.
-
The Login Manager sends ACK for the login to Web EngineA.
-
Web EngineA sends a response to Client A.
-
Client B that is using SessionB tries to log into Web EngineB with the ID UserA.
-
Web EngineB registers login information in the Login Manager.
-
The Login Manager detects a duplicate login.
-
The Login Manager tells Web EngineA to discard the existing session SessionA and Web EngineA deletes the session.
-
The Login Manager sends ACK for the login to Web EngineB.
-
Web EngineB sends a response to Client B.
Note
Since login event occurs in an application, methods for sending a login event from the JEUS Login Manager are limited. Jeus Login Manager recognizes a login event when the setAttribute is executed with the "JEUS_LOGIN_KEY". This value can be changed to "jeus.application.login.key" in jeus-web-dd.xml. Logout can be executed by using removeAttribute with the same key. Invalidated sessions are logged out automatically.
Multiple servers can share and use session data when distributed session servers form a cluster.
The following are the steps for creating a cluster in the WebAdmin.
-
Click [Clusters] from the left menu in the WebAdmin to go to the Clusters screen.
-
Change to configuration mode by clicking [Lock & Edit].
-
To add a cluster, click [Add], or to edit an existing cluster, click on the target cluster in the list from the Clusters screen.
-
In the Servers list, servers in the domain are displayed. Select the servers that will form the cluster as shown in the following figure, and then click [OK].
-
Complete the configuration and click [Apply Changes] to dynamically apply the changes.
-
The changes are applied and a result message is displayed.
Note
Since distributed session servers are automatically clustered, the configuration is applied dynamically, but non-clustered session servers may need to be restarted.
The following are the steps for configuring distributed session servers in the WebAdmin.
-
Click [Clusters] from the left menu of WebAdmin to go to the cluster search screen. In the clusters list, click the desired cluster and then open the [Session Router Config] tab.
-
Click [Lock & Edit] to change to the configuration mode.
-
Configure each item on the Session Router Config screen and press [OK]. To reset the configuration, click [Reconfiguration], and to delete the configured value, click [Delete].
The following describes each property.
-
Basic Information
-
Configures the primary and a secondary servers of Jeus Login Manager that performs duplicate login prevention. Configures a server where Jeus login manager saves the login information to prevent duplicate login at the cluster level.
-
Backs up modified session objects to a file. If the <shared> option is set to true, the backup is executed for each server. Otherwise, it is executed for each application.
The following describes each property.
-
-
Complete the session configuration and click [Apply Changes] to apply the changes.
-
The changes are applied and the following result message is displayed. The server must be restarted to apply the configuration changes on the Session Router Config screen.
This section describes session clustering.
In session clustering which includes basic clustering provided by JEUS, an application decides which session clustering it belongs to regardless of the server configuration. An application is deployed by selecting a session clustering and the session is maintained and managed in the cluster.
Except the clustering scope, the internal operation of session clustering is same as distributed session server. Session clustering allows session sharing between clusters, and each server can configure multiple session clusterings.
The following shows an example of configuring session clustering. Triangles, circles, and stars represent applications.
-
Server1 and server2 are tied to Server Cluster1.
-
Server3 and server4 are tied to Server Cluster2.
-
When an application is deployed to JEUS server cluster, the same application must exist in the cluster.
-
ApplicationA and C: server1 and server2
-
ApplicationB and D: server3 and server4
-
-
ApplicationA and ApplicationB are maintained and managed in each clustering through distributed session server clustering.
-
ApplicationC and ApplicationD can be shared beyond the cluster through session clustering of distributed session servers. Sessions are maintained and managed on all servers, server1, server2, server3, and server4.
Using session clustering as in the previous example allows various application configurations beyond the limits of the existing clustering.
Note
A common URL between applications is needed in order to share a session among different applications. This is not a restriction of JEUS but that of the browsers or cookies. Applications using session clustering must have a common URL configured to the session cookie path.
Using WebAdmin
The basic configuration for session clustering is the same as distributed session server configuration. Following are the steps for configuring session clustering in the WebAdmin.
-
Click [Session] from the left menu of WebAdmin.
-
Select 'Session Cluster Config' and configure 'Using Session Cluster'.
Subsequent configurations are common session clustering settings. They are only used if they are not configured in each individual session clustering. -
Click [ADD] to add a session clustering.
Click [ADD] and the Clusters' Session Router Config configuration screen appears. Configure each individual session clustering. -
To deploy applications to a session clustering, configure the session cluster where session clustering will be applied to in the <target-session-cluster> element of jeus-web-dd.xml.
Note
Since session clustering is a structure that determines session clustering in the application, a session cluster must be selected and configured in jeus-web-dd.xml.
This section describes the configuration changes between JEUS 6 and JEUS 7 using the four clustered servers from the example in [Figure 2.1].
The following are the differences between distributed session servers in JEUS 6 and JEUS 7.
-
In JEUS 6, each node requires a configuration file because distributed session servers can be configured using the node clustering system. However, in JEUS 7, since sessions are part of the cluster, the configuration is performed at the cluster level.
-
The manual backup configuration, <session-router>, has been removed from JEUS 7. Backup is now automatically configured through the GMS system.
-
In JEUS 6, each session thread pool is configured separately. In JEUS 7, the thread pools are unified and configured using the Reserved Thread Num option.
Note
The user must understand the concepts of the node and container used in JEUS 6 as well as that of the server used in JEUS 7. Server1 and server2 can be considered similar to container1 and container2 in JEUS 6. What was previously called a container in JEUS 6 is now called a server. The names of the nodes are MyNode and MyNode1.
The following shows an example of a distributed session server configuration in JEUS 6.
[Example 2.1] JEUS 6 Configuration: <<JEUSMain.xml>>
<jeus-system>
. . .
<node>
<name>MyNode</name>
<engine-container>
<base-port>3030</base-port>
<name>container1</name>
<engine-command>
<type>servlet</type>
<name>engine1</name>
</engine-command>
. . .
</engine-container>
<engine-container>
<base-port>3031</base-port>
<name>container2</name>
<engine-command>
<type>servlet</type>
<name>engine2</name>
</engine-command>
</engine-container>
. . .
<session-router-config>
<session-router>
<!-- Uses the full name which the node name, engine, and engine name are mixed together.-->
<engine-name>MyNode_servlet_engine1</engine-name>
<!-- When a particular backup is not desired,even when there's no configuration, it is automatically selected. -->
. . .
</session-router>
<session-router>
<!-- Uses the full name which the node name, engine, and engine name are mixed together.-->
<engine-name>MyNode_servlet_engine1</engine-name>
<!-- When a particular backup is not desired,even when there's no configuration, it is automatically selected. -->
</session-router>
</session-router-config>
. . .
</node>
. . .
<node>
<name>MyNode1</name>
<engine-container>
<base-port>3033</base-port>
<name>container1</name>
<engine-command>
<type>servlet</type>
<name>engine1</name>
</engine-command>
. . .
</engine-container>
<engine-container>
<base-port>3034</base-port>
<name>container2</name>
<engine-command>
<type>servlet</type>
<name>engine2</name>
</engine-command>
. . .
</engine-container>
. . .
<session-router-config>
. . .
<session-router>
<!-- Uses the full name which the node name, engine, and engine name are mixed together.-->
<engine-name>MyNode_servlet_engine1</engine-name>
<!-- When a particular backup is not desired,even when there's no configuration, it is automatically selected. -->
. . .
</session-router>
<session-router>
<!-- Uses the full name which the node name, engine, and engine name are mixed together.-->
<engine-name>MyNode_servlet_engine1</engine-name>
<!-- When a particular backup is not desired,even when there's no configuration, it is automatically selected. -->
. . .
</session-router>
</session-router-config>
. . .
</node>
. . .
</jeus-system>
For JEUS 7, distributed session servers can be configured in the WebAdmin. Configuring server clustering in JEUS 7 produces the same effect as configuring distributed session servers with four containers in JEUS 6. A distributed session server composed of four servers can be configured and used with the following configuration. For detailed information about clustering and the basic configuration of distributed session servers, refer to "2.6. Clustering" and "2.7. Session Server Configuration".
JEUS 7 allows the existing structure of JEUS 6 to be maintained and operate in JEUS 7 for those who are unfamiliar with the domain structure of JEUS 7. The JEUS 6 structure here means the deploy format as in the following example.
-
There are two nodes and each one creates two containers.
-
A separate application is deployed to each container. A total of four applications exist each on a separate container.
-
Sessions can be shared in the same node by setting the <shared> option, or they can be shared among different nodes using a central session server.
-
As a result, all sessions in the four containers are shared.
This method does not work with JEUS 7. JEUS 7 session servers use clusters by default, and different applications cannot be deployed to each server in the cluster. In other words, to deploy different applications on each physical server, the servers cannot belong to a cluster. JEUS 7 provides Http Session Config to allow servers to share sessions without being in a cluster.
Note
The aforementioned session clustering cannot be used with Http Session Config. This feature overrides the session clustering configuration.
However, Http Session Config is a configuration that is not compliant with the domain structure specification. It is provided for user convenience and the following restrictions must be considered for use.
-
Http Session Config only applies to web applications, not EJBs.
-
If clustering is also configured, the clustering configuration is ignored.
-
The configuration is set in domain.xml and applies to every server in the domain. It is not possible to configure individual servers.
-
The <shared> option is set to true which forces every application on every server to share the sessions.
The following are the steps for configuring Http Session Config in the WebAdmin.
-
Click [Session] from the left menu in the WebAdmin.
-
Click [Lock & Edit] to change to the configuration mode.
-
Select the Http Session Config check box, configure each item, and then press [OK]. The configuration items are the same as those on the Session Router Config screen. For detailed information, refer to section 7 of "2.7. Session Server Configuration".
-
Complete the configuration and click [Apply Changes] to apply the changes.
-
The changes are applied and a result message is displayed. The server must be restarted to apply the configuration changes on the HTTP Session Config screen.
