We have started using infinispan cache with wildfly 13 in our web application. The web application is deployed in wildfly domain mode in a cluster of two node with one acting as master and the other as slave. In the application we have an admin feature, where the admin can terminate a user.
So what we want to do is add session objects to Infinispan cache and retrieve it and terminate it when required. I am aware that HttpSession object is not serializable hence it cannot be added to cache but every attribute added to the session object is serilizable so my question is, is there a workaround for the issue? Because right now we get a NotSerializable error when I try to add session to cache and it's also no longer possible to retrieve session from sessionId and terminate it due to security reasons.
There is no need to manually interact with the Infinispan cache: WildFly transparently supports full http session clustering with Infinispan. See https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
Related
We have multiple application contexts deployed on WildFly.
Is it possible to have a global session expiry across all deployed applications so that if 1 application's session state has not expired, the rest of the application's session state cannot expire? Could this be achieved through configuring Single Sign On?
We would like to have the same behaviour as a portal containing many portlets where there is a portal session scope that contains portlets with their own session scope. The session expiry would correspond to inactivity within the portal session scope.
Please let me know if anyone out there has achieved what I've described above (but not with a Portal architecture).
Every application sets its session timeout in the web.xml each of them maintains sessions for users independent of the other applications in the server and this is the behavior all Java EE application servers by my experience. That said, if you configure SSO i will advice you set the same session timeout for all these applications in the web.xml and you can be sure of common session timeout.
I am in the progress of migrate my spring mvc + hibernate based application to clustered environment (Tomcat clustering). I am researching on the possible solutions for the session replication / sharing. From the Terracotta documentation
All clustered session implementations (including terracotta Sessions)
require a mutated session object be put back into the session after
it's mutated. If the call is missing, then the change isn't known to
the cluster, only to the local node. For example:
Session session = request.getSession();
Map m = session.getAttribute("foo");
m.clear();
session.setAttribute("foo", m); // Without this call, the clear() is not effective across the cluster.
Just want to know if the same rule holds true for Spring Session? I mean the Spring Session Project
Anyone knows the reason behind this rule? Is it because only when that method is called, Spring Session or Terracotta Web Session serialize the attribute object? Without this call, they don't know the object has changed? i.e. they won't monitor the object for changes?
Do you know a clustering solution that don't have this rule?
currently we are deploying to a cluster-scenario where we have 3 nodes (tomcat), all of them share their sessions via Hazelcast. We have an apache in front of these nodes as a loadbalancer.
curling our application, I see, that there are two session-cookies used:
1) is the usual tomcat session with a JSESSIONID
2) is the hazelcast-session with a hazelcast.sessionId
Is there any way to omit the JSESSIONID?
or
Is there any way to somehow "join" both?
Thanks in advance.
No, both are required in current implementation.
Hazelcast uses only hazelcast.sessionId as HttpSession.getId() and nearly everyplace to identify distributed session. But for some cases like failover Hazelcast uses both session identifiers (hazelcast.sessionId and JSESSIONID ) internally.
From Hazelcast documentation:
SessionId Generation
SessionId generation is done by Hazelcast Web Session Module if session replication is configured in the web application. Default cookie name for the sessionId is hazelcast.sessionId and this is configurable with cookie-name parameter in the web.xml file of the application. hazelcast.sessionId is just a UUID prefixed with “HZ” character and without “-“ character, e.g. HZ6F2D036789E4404893E99C05D8CA70C7.
When called by the target application, the value of HttpSession.getId() is the same as the value of hazelcast.sessionId.
I set up two equal tomcat servers that host the same web application (Sun RI JSF 2 / Tomahawk). For load balancing and fail-over scenarios I use an nginx server as reverse proxy delegating the request to the one or the other server. Right now one tomcat is defines as backup solution, so that tomcat server 1 handles all the requests. When I kill the process of tomcat 1, nginx nicely delegates the following requests to tomcat server 2. In order to reuse the session data I configured both tomcat servers to use memcached as session store. JSF is configured to store its state on the server.
Concerning the log files, this setup looks quite nice and session data is read and stored using the memcached server. This for example facilitates using the web application without the need to login again even if tomcat 1 has been shut down.
Nevertheless it seems as if my (session scoped) backing beans are not stored or being used after restoring the session respectively. Form fields are left empty that are supposed to be filled with the data from the session bean.
Is it possible to do such things with the mentioned technologies at all?
With memcached-session-manager and OWB you should use tomcat < 7.0.22 as in this version the notification of ServletRequestListeners got changed (which is the mechanism used by OWB for failover support).
I'm currently working on a new version of msm that works with OWB and tomcat >= 7.0.22.
Where does Tomcat or Jetty saves the sessionids (without session persistence configuration)? Does it go anywhere in the file system, or does it stay just in memory?
Tomcat uses the StandardManager by default to manage it's session data. During run-time this data is not persisted to a store and exists only in memory. When you shutdown Tomcat it will try to persist all the session data to $TOMCAT_HOME/work/Catalina///SESSIONS.ser. Tomcat will try to reload these session on next startup and it will also delete the SESSIONS.ser file after a successful start. If your server dies or you execute a kill -9 this session data will be lost.
Documentation for the StandardManager is here http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html
I don't know Jetty very well but Jetty does not have any persistence by default so the sessions are in memory. You can enable persistence if you want and its documented here docs.codehaus.org/display/JETTY/Persisting+Sessions.
Hope this helps.