|Summary:||Session is lost when application is reloaded through touching the war file|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description adrianosf 2009-03-26 16:18:25 UTC
Created attachment 23419 [details] Example project I tried a very basic example, based on Maven quickstart. web.xml is almost empty, and a jsp page: ================= <html> <body> <% String x = (String) request.getSession(true).getAttribute("x"); if (x == null) x = "0"; int y = Integer.valueOf(x) + 1; request.getSession(true).setAttribute("x", String.valueOf(y)); %> <%= y %> </body> </html> ================= So I start reloading the page. The number increments. I can stop/start or reload the app. The number continue incrementing. Then I touch (with gnuwin32 touch utility) the war file. The Tomcat console displays: ================= 26/03/2009 11:11:28 org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started 26/03/2009 11:12:02 org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/example] 26/03/2009 11:12:02 org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive example.war ================= You see, it undeployed, and the counter has reseted. Now, I tried delete webapps/example. After some seconds, the war is exploded and same thing as above happens. Then I tried to delete webapps/example/*, leaving the directory empty. This way, I can manually extract the war there, and session is preserved. Charles (Chuck) Caldarale, said this is an inconsistency worth registering.
Comment 1 Kirk True 2009-04-07 09:06:21 UTC
In addition to the OP seeing this on Windows on 6.1.18, I am able to reproduce this on Linux against the trunk. OP - thanks for the example (Maven) project and the clear steps. There are three cases discussed; this is what happens presently: * Touching $TOMCAT_HOME/webapps/example.war - sessions deleted * Deleting $TOMCAT_HOME/webapps/example - sessions deleted * Deleting $TOMCAT_HOME/webapps/example/* - sessions preserved So what is the expected behaviour with regard to the above cases?
Comment 3 adrianosf 2009-04-07 09:52:14 UTC
I would like to add, althrough that may be a different problem, that in some cases (probably for larger [20mb] war files), when you start replace a war with another, Tomcat starts the new deploy before the war file is entire writen. That causes errors as corrupted war file.
Comment 4 Kirk True 2009-04-07 10:15:20 UTC
Yeah, I've noticed this problem too. I wonder if there should be some kind of idle wait that waits for N milliseconds without a file change before trying to unzip.
Comment 5 Pid 2009-04-07 10:58:31 UTC
(In reply to comment #3) > I would like to add, althrough that may be a different problem, that in some > cases (probably for larger [20mb] war files), when you start replace a war with > another, Tomcat starts the new deploy before the war file is entire writen. > That causes errors as corrupted war file. If your filing system takes longer than the war deployer monitor interval to copy 20Mb you have a very slow harddrive and should consider upgrading. If on the other hand you are FTPing a war file straight into your webapps dir, then you should probably rethink your strategy - as that's not the most sensible approach - e.g. rename before upload, upload to safe temp dir, etc.
Comment 6 Mark Thomas 2009-04-15 15:57:03 UTC
Good news and bad news I am afraid. The good news is that this is 'fixed'. The bad news is that the fix is making the docs clearer that Tomcat is working as designed in this case. There are ways to achieve an update to an application without dropping the sessions. The simplest is probably: - deploy as an exploded directory rather than a WAR - update the files - touch web.xml to trigger a reload This is only one way. If you want to discuss the alternatives then please use the users list. The reason for the current behaviour is to prevent problems when WARs are updated in incompatible ways and anything other than a full undeploy followed by (essentially) a new deployment causes conflicts. The updated docs are in trunk and 6.0.x and will be included in 6.0.20 onwards.