Summary: Global HTTP Session Sharing allows transparent session replication between remote sites and session sharing between different application servers in real-time. The solution uses the
Shiro Session Manager library
Global HTTP Session Sharing - Massive Web Application ScalingIt's becoming increasingly important for organizations to share HTTP session data across multiple data centers, multiple web server instances or different types of web servers. Here are few scenarios where HTTP session sharing is required:
Global Http Session Sharing
View
more presentations or
Upload your own.
The following image depicts a common use case where there are multiple data centers connected across the WAN, and each is running a different type of web server. The GigaSpaces Global HTTP Session Sharing architecture allows users to deploy their web application across these multiple data centers where the session is shared in real-time and in a transparent manner. The HTTP session is also backed by a data grid cluster within each data center for fault tolerance and high-availability. With this solution, there is no need to deploy a database to store the session, so you avoid the use of expensive database replication across multiple sites. Setting up GigaSpaces for session sharing between each site is simple and does not involve any code changes to the application. What does GigaSpaces Global HTTP Session Management provide?GigaSpaces Global HTTP Session Management designed to deliver the application maximum performance with ZERO application code changes. GigaSpaces Global HTTP Session Management features the following:
Using GigaSpaces Global HTTP Session Sharing with your ApplicationYou simply need to configure your web application to use the Shiro session manager with GigaSpaces, deploy the GigaSpaces in-memory data grid (IMDG) and its WAN Gateway in each data center and deploy your web application. That's it! There is no need to change the web application or plug in any custom code in order to enable session sharing between servers running in remote data centers. In addition, you don't have to add the HTTP session classes to the IMDG classpath. The below diagram shows a more detailed view of the IMDG deployment. In this case, there are multiple partitions for high scalability, as well as backup instances for redundancy. The WAN Gateway is also deployed and shows replication to each remote site. The end-to-end path between the 2 data center nodes includes the servlet and Shiro filters, and the IMDG with local cache and WAN Gateway. Load-Balancing ScenariosThe GigaSpaces Global HTTP Session Sharing support two Load-Balancing scenarios: Session Sharing Scenario
Session Failover Scenario
The Web ApplicationThe web application requires a couple of configuration changes to the web.xml file in order to include the Shiro filter:
The WEB_INF/web.xml file
<web-app> .... <listener> <listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class> </listener> <listener> <listener-class>org.openspaces.sessions.shiro.GigaCacheManager</listener-class> </listener> <filter> <filter-name>ShiroFilter</filter-name> <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class> </filter> <filter-mapping> <filter-name>ShiroFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> </web-app>
The shiro.ini file needs to be placed within the WEB-INF folder and to define parameters for the session manager for it to be able to access GigaSpaces:
The WEB_INF/shiro.ini file
[main] sessionManager = org.apache.shiro.web.session.mgt.StandardWebSessionManager #set the sessionManager to use an enterprise cache for backing storage: sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO sessionManager.sessionDAO = $sessionDAO sessionDAO.activeSessionsCacheName = jini://*/*/sessionSpace # ensure the securityManager uses our native SessionManager: securityManager.sessionManager = $sessionManager # whatever your CacheManager implementation is, for example: cacheManager = org.openspaces.sessions.shiro.GigaCacheManager # Session data TTL/Lease in milliseconds # In a multi container non-sticky mode, session should expire from GigaSpaces based on sessions last accessed time # Default lease is 30 minutes - 30 * 60 * 1000 = 1800000 cacheManager.sessionLease = 1800000 # This will use GigaSpaces for _all_ of Shiro's caching needs (realms, etc), # not just for Session storage. securityManager.cacheManager = $cacheManager # Session validation sessionValidationScheduler = org.apache.shiro.session.mgt.ExecutorServiceSessionValidationScheduler # Session timeout securityManager.sessionManager.defaultSessionTimeout = 1800000 # Default is 3,600,000 millis = 1 hour: sessionValidationScheduler.interval = 1800000 sessionValidationScheduler.sessionManager = $sessionManager securityManager.sessionManager.sessionValidationScheduler = $sessionValidationScheduler
Web Application LibrariesThe web application should include the following libraries within its \WEB-INF\lib file folder:
GigaSpaces In Memory Data Grid (IMDG)GigaSpaces IMDG should be deployed using your favorite topology (replicated and/or partitioned, static or elastic) and include a reference to a WAN Gateway. Before deploying regular IMDG:
To deploy the IMDG start the GigaSpaces agent using the gs-agent and run the following: gs deploy-space sessionSpace
The WAN GatewayThe WAN Gateway should be deployed using your preferred replication topography, such as multi-master or master-slave. See the WAN Replication Gateway best practice for an example of how a multi-master Gateway architecture can be deployed. Other configuration optionsNon-Serializable Session DataThere are cases when applications store session data which is not defined as serializable. To support non-serializable session data you can configure the session manager to serializable session to XML by defining following parameter in shiro.ini file mentioned above, # Session serializationType - JAVA/XML (default JAVA)
cacheManager.serializationType = XML
Session manager uses XStream libraries for serializing session data to XML. XStream serialization can be further customized, application can configure GigaSpaces session manager to use Refection Converter for Externalizable classes and register custom converters. Following two parameters in shiro.ini file can help in customizing serialization, # When using Externalizable classes with customized serialization and want to stick to serialization based on Reflection enable this option # Default value is false # cacheManager.registerReflectionConverter = true # List of XStream converters that application would like to register # (Expecting that these are part of classpath or WEB-INF/lib) # Pass them comma separated # cacheManager.converterNameList = org.openspaces.xtreme.converter.XmlCalendarConverter Secured GigaSpaces clusterWhen using a Secure GigaSpaces cluster you can pass security credentials using following parameters in shiro.ini file, # When using secured GigaSpace cluster, pass the credentials here # cacheManager.username = gs # cacheManager.password = gs Http Session Web Application ExampleSingle-Site DeploymentThe example can be deployed into any web server (Tomcat, JBoss, Websphere, Weblogic, Jetty, GlassFish....).
Multi-Web Servers DeploymentMultiple TabsYou may share the HTTP session between different web servers. To test this on your local environment you can install multiple web servers, deploy the web application and have your browser access the same application via the same browser. See the below example: Hit the Refresh button when switching between the tabs. The session data will be refreshed with the relevant app server reading it from the space.
Load-BalancerAnother option would be to use a load-balancer such as the apache httpd and configure it to load-balance the web requests between the different web servers. Here is a simple setup:
Multi-Site DeploymentWhen deploying the multi-site example you should change the shiro.ini for each site to match the local site Space URL. For example, sessionDAO.activeSessionsCacheName = jini://*/*/wanSpaceDE?useLocalCache&groups=DE
To connect to the US space you should have the web application use a shiro.ini with the following: sessionDAO.activeSessionsCacheName = jini://*/*/wanSpaceUS?useLocalCache&groups=US
Other ConsiderationsWeb Application ContextGlobal HTTP session sharing works only when your application is deployed as a non-root context. It is relying on browser cookies for identifying user session, specifically JSESSIONID cookie. Cookies are generated at a context name per host level. This way all the links on the page are referring to the same cookie/user session. WebSphere Application Server HttpSessionIdReuse Custom PropertyWhen using the Global HTTP session sharing with WebSphere Application Server , please enable the HttpSessionIdReuse custom property. In a multi-JVM environment that is not configured for session persistence setting this property to true enables the session manager to use the same session information for all of a user's requests even if the Web applications that are handling these requests are governed by different JVMs. Transient AttributeAn attribute specified as transient would not be shared and its content will not be stored within the IMDG. Your code should be modified to have this as a regular attribute that can be serialized. |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |