You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2009/03/27 00:18:27 UTC
DO NOT REPLY [Bug 46924] New: Session is lost when application is
reloaded through touching the war file
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
Summary: Session is lost when application is reloaded through
touching the war file
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: adrianosf@gmail.com
Created an attachment (id=23419)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23419)
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 46924] Session is lost when application is
reloaded through touching the war file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
--- Comment #3 from adrianosf@gmail.com 2009-04-07 09:52:14 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 46924] Session is lost when application is
reloaded through touching the war file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Mark Thomas <ma...@apache.org> 2009-04-15 15:57:03 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 46924] Session is lost when application is
reloaded through touching the war file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
--- Comment #4 from Kirk True <ki...@mustardgrain.com> 2009-04-07 10:15:20 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 46924] Session is lost when application is
reloaded through touching the war file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
--- Comment #1 from Kirk True <ki...@mustardgrain.com> 2009-04-07 09:06:21 PST ---
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?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 46924] Session is lost when application is
reloaded through touching the war file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
--- Comment #2 from Kirk True <ki...@mustardgrain.com> 2009-04-07 09:12:02 PST ---
Whoops - regarding comment 1:
s/6.1.18/6.0.18/g
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 46924] Session is lost when application is
reloaded through touching the war file
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46924
--- Comment #5 from Pid <bu...@pidster.com> 2009-04-07 10:58:31 PST ---
(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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org