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. Distributed session servers are used to manage session data.
Note
For versions earlier than JEUS 7, central session server was used. Due to problems with centralized management of the system, only distributed session servers are used in JEUS 7 and later.
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, removeAttribute, and setMaxInactivateInterval, 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.10.3. Distributed Session Server Configuration Details".
-
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 that is not related to environment configuration. The connection to the remote engine is verified through SCF instead of constant pinging to avoid sending repeated error messages for an ongoing error situation.
Note
Previous versions of JEUS only recognizes the backup engine that is fixed in the configuration file. Now, it 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
The routing information is given as 'domain1/server1' for the reader, 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, a new session is 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 request-response method.
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.
-
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 how to process multiple requests that use sessions.
A session is an object used for a request. Session specifications do not guarantee session manipulation in another JVM or thread. The manipulation must be guaranteed by an application, which is not recommended.
If an application needs to send concurrent requests, the requests must be either sent to different sessions or must not use a session. This is required for a normal operation. However, some recent applications are implemented for multiple requests using a shared session.
The following issues may occur when multiple requests are processed using sessions.
-
Multiple sessions can be created at the same time. Since only one of them is maintained using a cookie, memory is wasted.
This issue occurs when requests are sent to different JVMs or processed at the same time. Since a new session is created by default if there is no available session, concurrent requests result in creating multiple sessions. The sessions are stored in cookies of a user browser. Since the cookies are managed within one scope, the last session information overwrites all the other session information. Therefore, the other sessions cannot be accessed and removed after a timeout period.
-
A session may not be maintained according to a method for maintaining the session in multiple JVMs. This issue is related to sticky session routing and occurs only when requests are sent to multiple servers or web engines. When multiple requests are sent to multiple JVMs at the same time, sessions may be lost according to a session maintaining method.
-
Multiple sessions may not be updated if they are tried to be updated at the same time.
This issue occurs only when requests are sent to multiple servers or web engines like in the above issue. Since one request must be sent to update one session, updating multiple sessions has the similar issue that occurs when creating multiple sessions.
The above three issues can occur in any environment as well as JEUS. JEUS performs migration to efficiently use local sessions, which may result in the occurrence of the second issue.
As described above, no issue occurs when concurrent requests are sent to the same server or web engine. However, if an application sends concurrent requests to multiple servers or web engines, sessions are lost as in the above figure. To prevent this, migration, which is used to efficiently use local sessions, can be disabled.
The following figure shows how to disable migration.
Although concurrent requests are sent to multiple servers, sessions are not migrated and copied for local manipulation. Manipulation results are updated in a server with ownership of each session. Disabling migration prevents losing sessions and has no issue when used to simply check session values. However, since the issues 1 and 3 still exist, disabling migration is not recommended.
Note
Since a session is a temporary object used to save and manage simple information, it must not be used like a database which exists in all systems. Use a session only to refer to an object value. It is not recommended to use a structure or configuration in which multiple requests are sent to multiple servers concurrently.
This section describes JEUS session cluster modes.
Session clustering is used to share sessions. Sessions must be shared within the same scope and must not be shared in different scopes. A session scope is determined according to a cluster mode.
JEUS supports the following three session cluster modes.
JEUS supports the default session cluster mode by default.
When servers are clustered, this mode is supported automatically and session data can be shared and used by the servers. Since this mode complies with servlet's basic session scope specifications, each application can manage a session independently and basic session clustering functions, such as failback and load balancing, are supported. The default scope is an application. Clustered servers can be a scope by using the Shared option provided by a web engine session manager.
In the domain-wide session cluster mode, all applications deployed in servers within a domain are regarded as a scope.
The default session cluster mode is restricted (targets to be deployed in a server) by a cluster structure because the mode depends on the cluster. In JEUS 6, different applications are deployed in each container and all containers' sessions can be shared. The following sample scenario describes more details.
-
There are two nodes and each node has two containers.
-
A different application is deployed in each container. That is, a total of four applications exist.
-
Sessions in the same node can be shared using the Shared option. Sessions in the other node can be shared using a central session server.
-
As a result, all sessions in the four containers can be shared.
The above scenario does not match the server cluster concept. Since all applications must be shared in a cluster, an application is forcibly deployed in all servers in the cluster. In a reliable environment, forcibly deployed applications may waste resources. However, they prevent the occurrence of a service not being available because a deployed application only physically exists in a specific server even though the server is included in a cluster. Therefore, a server must not be clustered to deploy a different application in each server.
The DOMAIN_WIDE mode is used to use a session cluster without a server cluster. The mode does not comply with domain structure specifications and is supported for user convenience. Note the following restrictions.
-
The mode is not related to EJB and only affects web applications.
-
If a server cluster as well as the mode are configured, the server cluster configurations will be ignored.
-
If the mode is set in domain.xml of a domain, it is applied to all servers in the domain. Some servers in the domain cannot be specified as a target of the mode.
-
Since the Shared option is set to 'true', sessions of all applications in all servers are forcibly shared.
Note
The domain-wide session cluster mode overrides server clusters.
In the specific-scope session cluster mode, specific applications are grouped and their sessions are shared regardless of a server cluster. This mode is used when multiple application groups exist. It differs from the basic session cluster or domain-wide session cluster mode in that the latter are generally used when only one application group exists.
If there are multiple application groups, sessions of applications included in a specially-defined scope across selected groups are shared. The session cluster has a different scope from distributed session servers, but it operates in the same way as the servers. Through the specific-scope session cluster mode, sessions can be shared between server clusters and multiple scopes can be configured for a single server.
The following example describes the specific-scope session cluster mode.
-
server1 and server2 are included in a server cluster named Server Cluster1.
-
server3 and server4 are included in a server cluster named Server Cluster2.
-
The same applications must be deployed in all servers in a JEUS server cluster.
-
Applications A and C are deployed in both server1 and server2.
-
Applications B and D are deployed in both server3 and server4.
-
-
Sessions of applications A and B are shared only in each server cluster through distributed session server clustering.
-
Sessions of applications C and D can be shared across the clusters through specific-scope session clustering of distributed session servers. That is, sessions of the applications can be maintained and managed in all servers: server1, server2, server3, and server4.
Specific-scope session clustering allows various application configurations, and are not restricted by specific clusters.
Note
To share a session between applications, a common URL to be used by the applications is necessary due to a restriction in browsers and cookies, not JEUS. Applications using session clustering must have a common URL, and the URL must be set in a session cookie path.
This section describes the basic configuration of a session cluster.
A session cluster is used to share sessions. In addition to the cluster, to share sessions, a distributed session server operates in a web engine and supports related functions. The operations and functions can be configured using WebAdmin.
The following describes how to configure basic session cluster information applied to an entire domain by using WebAdmin.
Select [Session] from the left menu of WebAdmin to display a session cluster configuration page.
The following shows a page for basic configurations applied to an entire domain.
The Session page is divided into Session Cluster and Specific Scope Cluster areas. The Session Cluster area is classified into configurations applied to an entire domain and common cluster configuration.
-
Session Cluster
Item Description Cluster Mode Session cluster mode.
-
DEFAULT: support a session cluster only when there is a server cluster. A session cluster in application units is supported by default. To use the SPECIFIC_SCOPE session cluster mode, use this value. (Default value)
-
DOMAIN_WIDE: support a session cluster where sessions for all applications in all servers in a domain are shared.
Each session cluster mode has a different scope, but uses the same distributed session server configuration options. For information about how to configure clustering methods and distributed session servers for each mode, refer to "2.10. Configuration for Each Session Cluster Mode".
Session Manager Provider Implementation to be used as a session manager. An entire package name or a reserve word (RUNTIME or JEUS) can be set.
-
RUNTIME: use an implementation that is not a JEUS provider, if one exists. (Default value)
-
JEUS: use a JEUS implementation.
Exclude Das in Cluster Option to exclude DAS from a session cluster. This has an effect only on the domain-wide session cluster mode.
-
true: DAS operates as a standalone server even though the DAS is included in a cluster.
-
false: DAS operates as a cluster member like other servers if the DAS is included in a cluster. (Default value)
Properties Properties are applied to all clusters and session servers in a domain. A pair of a key and a value can be set. Sticky Encoding Rule Encoding rule to be applied to sticky routing target information. Currently, the following two rules can be set.
-
BASE64: encode information by using the BASE64 rule in order to not expose the engine or domain information through a session ID. (Default value)
-
RAW: do not encode information. This value is used for debugging because it is difficult to determine an engine that sent a request by using encoded information or when there is no security issue even though an engine name has been exposed.
-
This section describes where and how a session cluster and a distributed session server can be configured for each session cluster mode.
The following describes how to configure a session cluster for each session cluster mode.
Default Session Cluster Mode
The following is the process of configuring a server cluster to use the default session cluster mode.
-
Select [Clusters] from the left menu of WebAdmin to display the Clusters page.
-
Click [Lock & Edit] to modify configurations.
-
To add a cluster, click [Add]. Or, to modify a cluster, select a cluster from the displayed cluster list.
-
Select servers from 'Servers' to be included in a cluster, and then click [OK].
-
To dynamically apply the configuration, click [Apply Changes].
-
If the configuration is applied, the following message will be displayed.
Note
The clustering configuration is dynamically applied to distributed session servers. However, applying the configuration to application-scope session servers may require restarting the servers according to deployed applications.
Domain-wide Session Cluster Mode
The following is the process for using the domain-wide session cluster mode.
-
Select [Session] from the left menu of WebAdmin to display the Session page.
-
Click [Lock & Edit] to modify configurations.
-
Select 'DOMAIN_WIDE' in 'Cluster Mode'.
-
To apply the configuration, click [Apply Changes].
-
If the configuration is applied, a result message will be displayed. Since the configuration is not applied dynamically, the server must restart to actually apply the configuration.
Specific-scope Session Cluster Mode
The specific-scope session cluster mode can be regarded as a detailed mode of the default session cluster mode. To use this mode, configure the default session cluster mode in detail.
The following is the process for using the specific-scope session cluster mode.
-
Select [Sessions] from the left menu of WebAdmin to display the Session page.
-
To add a cluster, click [Add] at the bottom of the page. In the displayed Session Cluster Config page, which is the same as the page in the Clusters page, configure a session cluster.
-
To apply the configuration, click [Apply Changes].
-
To deploy an application in this mode, configure a session cluster in <target-session-cluster> of jeus-web-dd.xml.
Note
Since a session cluster depends on applications, a session cluster must be selected and configured in jeus-web-dd.xml.
A distributed session server can be configured in the following three pages in WebAdmin.
Common Cluster Config
Select [Sessions] from the left menu of WebAdmin to display the Session page.
Under the figure [Figure 2.10], the following part is located. For information about each item, refer to "2.10.3. Distributed Session Server Configuration Details".
Configurations in Common Cluster Config are applied or not applied according to the value in Cluster Mode (described in "2.9. Basic Configuration for a Session Cluster").
| Classification | Description |
|---|---|
| The default session cluster mode (DEFAULT) | Configurations in Common Cluster Config are used when there is no configuration for a distributed session server based on a server cluster. If there is no server cluster or there are configurations for a server cluster, these configurations will be ignored. |
| The domain-wide session cluster mode (DOMAIN_WIDE) | Configurations in Common Cluster Config are used as configurations for a distributed session server that are applied to an entire domain. |
| The specific-scope session cluster mode (SPECIFIC_SCOPE) | Configurations in Common Cluster Config are used when there is no configuration for the specific-scope session cluster mode. If there are configurations for a cluster in the mode, these configurations will be ignored. |
Cluster Session Cluster Config
Select [Clusters] from the left menu of WebAdmin to display a cluster list.
Select a cluster and then click the [Session Cluster Config] tab to configure the distributed session server.
The configurations have an effect only on the default session cluster mode. If these configurations are not specified, configurations in Common Cluster Config are used for one or more session clusters. Different configurations can be used for each server cluster. For more information about the items on this page, refer to "2.10.3. Distributed Session Server Configuration Details".
Specific-scope Session Cluster Config
Select [Clusters] from the left menu of WebAdmin to display a list of session clusters with a specially defined scope under the figure [Figure 2.10].
Select a cluster name to display the configurations for the distributed session server.
The configurations have an effect only on the specific-scope session cluster mode. If these configurations are not specified, configurations in Common Cluster Config are used for one or more session clusters. Different configurations can be used for each scope. For more information about the items in this page, refer to "2.10.3. Distributed Session Server Configuration Details".
The following describes pages and items in the pages for configuring a distributed session server.
 |
 |
 |
-
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.