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.
Related
I am trying to make Spring session persistence work but so far no luck.
So I start the app, do log in, change Java code to force restart and session is lost after that.
Enabled session persistence using server.servlet.session.persistent=true.
I see this property is picked up, and Tomcat is configured properly.
After some debugging I found out that the doUnload() method in org.apache.catalina.session.StandardManager is called properly but the session map is empty!
This happens in https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/05aeff976f6a75346c95cf6d3a9c8add8b9cb0bc/java/org/apache/catalina/session/StandardManager.java#L338.
Any idea why this is happening? I did log in so I expect session to be created...
Spring Boot 2.1.1.RELEASE, Tomcat started at same version
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
I have a sprig boot app leveraging websockets using tomcat. The app is writing stuff to the database constantly, and now I would like to implement a proper shutdown procedures i.e.
I have found a way to tell in my Service Layer to wait until all database transactions has finished however I would like to tell tomcat during that time that he shell not accept new connection i.e. only process the the currently established one. Tomcat should run but all new sessions should be denied.
I can get all the currently logged in users trough the “SessionRegistry” bean and invalidate their sessions, once all database transactions has finished, but that does not prevent anyone form creating new session during that time. So my question is how to I tell tomcat to stop accepting new session but not to drop the currently created one and let them finish. Is there something like that build in into tomcat?
Addition : 15 March 2018
I think i found the answer look
here
Hope that this will be useful for someone
I wrote a Spring Boot webservice that uses an embedded tomcat as container.
In case the system reboots I want to backup some information to a mysql database.
In my webservice I use #Scheduled() and #PreDestroy to run the backup.
This goes well when I stop the server with ^C.
But when I kill the process with an sysV skript (/etc/init.d) and the kill command - even though the daemon has a dependency on mysql, the mysql server is shut down before the backup is finished (resulting in SQL Exceptions in my log).
The reason for this is of course, that kill only sends a signal to stop the process.
How can I (from my sysv skript) synchroneously stop the running spring boot tomcat server?
If you include spring-boot-starter-actuator then that provides a REST endpoint for management. One of the endpoints provided is /shutdown. By hitting that endpoint, you will get a controlled shutdown of all resources, which ensures that #PreDestroy will be called. As this could be dangerous to have enabled by default, to use it you will need to add the following to your application.properties file:
endpoints.shutdown.enabled=true
Of course, once you have exposed that endpoint you need to ensure that there's a teeny bit of security applied to prevent just anybody shutting down your server.
On a related note, you may find my answer to Spring Boot application as a Service useful, where I provided the code for a full init.d script which makes use of this.
As an alternative to the "/shutdown" endpoint the Actuator also has an ApplicationPidListener (not enabled by default) that you can use to create a pidfile (which is commonly used in "init.d" style scripts to kill a process when you want to stop it). The JVM should respond to a kill (sigint) and Spring will shutdown gracefully.
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.