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.8. 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.
This section describes failback for distributed session servers.
Failback is a basic function for session servers. It allows for a service to continuously operate even during a failure situation. That is, although a failure occurs in a server, a session is not lost and continuously provides a service because the session’s backup is dumped to another session.
Failback provided by JEUS is for not only one failure but also consecutive failures, such as multiple servers’ consecutive restart, and recovery of a server with a failure. The following explains this with a scenario that two servers restart consecutively.
The following figure shows the scenario when failback is not supported.
If Server1 restarts, session A that belongs to the Server1 exists only in Server2 as backup. If Server2 restarts later, its backup will be removed, which means that the session A is removed from the entire system. If there is a request for the session A, an existing session cannot be used and a new session will be created. This is because session backup is not processed in previous distributed session servers.
The following figure shows the scenario when failback is supported.
When Server1 restarts, DumpToBackup for session B is the same as in the case that failback is not supported. Additionally, session A in Server1 is recovered by performing failback with backup of session A in Server2. Even after Server2 restarts later, all sessions are maintained.
Note
Even though failback is not supported, a session is maintained if there is an access to the session when a server failure occurs (failover). This is possible because a backup session exists. The accessed session is backed up again to another server (DumpToBackup), it can operate normally. For this, some web servers try to maintain all sessions by accessing them.
Failback is basically executed based on the reply-response method. <jeus.sessionmanager.failback.allow> must be set to true in a server with a failure.
When server A is used as a backup server for server B, failback starts if the server A detects that the server B restarts.
-
Server A checks whether server B restarts and to have backup of server B’s sessions.
-
If the server A confirms that it has the backup of the server B’s sessions, it sends a request to the server B whether the server B will be failed back.
-
If <jeus.sessionmanager.failback.allow> is set to true, the server B sends a response to the server A for failover.
-
The server A transfers backup of the server B’s sessions to the server B.
Note
If OOM occurs, failback is not recommended. If too many sessions are backed up, failback may cause OOM continuously. Failback is supported for rolling patches because servers need to be restarted consecutively without a session disconnection.
This section describes session clustering.
Session clustering supports session sharing. Sessions must be shared within a scope and must not be shared outside the scope. JEUS supports 3 types of session clustering according to a session scope: application, domain, and user-defined scope session clustering.
Application scope session clustering is the most basic and widely used session clustering.
When servers are clustered, application scope session clustering is automatically supported. Session data can be shared and used by the clustered servers. Since this session clustering follows servlets’ basic session scope, each application manage a session independently, and session clustering’s basic functions such as failback and load balancing are supported. The default scope is an application, but sever scope can also be supported if the Shared setting provided by a web engine session manager is used.
Clustering Configuration
Application scope session clustering can be configured simply by setting a cluster between servers.
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.
Domain scope session clustering (Http Session Config) operates with a more intuitive structure than that of application scope session clustering.
In JEUS 6, different applications are deployed in each container and all containers’ sessions can be shared. Users who are familiar with JEUS 6 structure may have difficulty in understanding JEUS 7 domain structure because all applications are forcibly deployed in a cluster.
The following is a detailed example in JEUS 6.
-
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.
The previous JEUS 6 example does not work with JEUS 7. In JEUS 7, since all applications are forcibly deployed in a cluster, the same applications are deployed in all servers in the cluster. This may waste resources in a reliable environment. However, it prevents that a service is not available because a deployed application only exists in a specific server physically even though the server is included in a cluster.
JEUS 7 allows to use session clustering without clustering servers by using the Http Session Config function.
Note
Domain scope session clustering will be used if Http Session Config is set even when servers are clustered.
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.
HTTP Session Configuration
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.8. 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.
Applications can be grouped and used by shared sessions. When multiple application groups exist, user-defined scope session clustering can be used. An application group is deployed in a selected session cluster and managed within the scope of the selected session.
It is recommended to use application or domain scope session clustering because only one application group is used in most cases.
Except the clustering scope, the internal operation of user-defined scope 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
1. Domain scope session clustering will be used if Http Session Config is set even when servers are clustered.
2. 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.
Session Clustering Configuraiton
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. -
After saving the configuration, click [Activate Changes].
-
To add session clustering, click [ADD]. The same screen as the Clusters' Session Router Config screen appears. Configure individual session clustering.
-
To apply individual session clustering configuration, click [Activate Changes].
-
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.
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 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.7. Session Clustering" and "2.8. Session Server Configuration".
