Peter,
you saved me. Thanks a lot!
I also upgraded to using the deploy-task with update="true" and got even
better behavior than before.
Application-update works with a sub-second downtime now.
BTW I use in META-INF/context.xml:
<Context>
<Manager pathname="${catalina.base}/conf/Catalina/myapp_SESSIONS.ser" />
</Context>
as the path. This it is working out of the box without creating dirs and
setting permissions.
Reinhard
Am Dienstag, 14. März 2006 16:29 schrieb Peter Rossbach:
> Please open a bug report,
> then we can better discuss the issue.
>
> Peter
>
> Am 14.03.2006 um 16:21 schrieb Reinhard Moosauer:
> > Hi Peter,
> >
> > thanks for making it clear.
> >
> > I would appreciate your opinon in how we could enhance this:
> >
> > - I think, even on production systems, there should be a
> > possibility to
> > do a 'soft' application update without interrupting all users.
> > When only minor changes in the application are made, the session
> > state
> > should be fully compatible.
> > - I agree, that in many situations, a clear state is very much
> > helpful.
> > But this applies even more to development systems, doesn't it?
> > - I hoped, we could simply add a manager attribute 'keepSessions'
> > to the
> > undeploy-task. But I am afraid, that's no easy to get, because
> > deletion is
> > not done in the manager but in the context.
> > Do you think its possible?
> > - It would be quite straightforward, if the 'update'-attribute to
> > manager-deploy would have just this effect.
> >
> > If anyone has a good idea how to do this, please let me know.
> > All other please vote for this enhancement because we have lost a
> > very nice
> > feature here.
> >
> > kind regards,
> >
> > Reinhard
> >
> > Am Dienstag, 14. März 2006 15:44 schrieb Peter Rossbach:
> >> Hmm,
> >>
> >> I thing you are right.
> >>
> >> ContextConfig.destroy() remove the working dir after undeploy the
> >> app.
> >>
> >> /**
> >> * Process a "destroy" event for this Context.
> >> */
> >> protected synchronized void destroy() {
> >> // Called from StandardContext.destroy()
> >> if (log.isDebugEnabled())
> >> log.debug(sm.getString("contextConfig.destroy"));
> >>
> >> // Changed to getWorkPath per Bugzilla 35819.
> >> String workDir = ((StandardContext) context).getWorkPath();
> >> if (workDir != null)
> >> ExpandWar.delete(new File(workDir));
> >> }
> >>
> >> This feature is important do guaranty a clear state after change the
> >> binary. Feel free to open
> >> an enhancement bug report, and feel free to add a patch. The current
> >> behaviour is
> >> correct for production sites.
> >>
> >> Peter
> >>
> >> Am 14.03.2006 um 15:03 schrieb Reinhard Moosauer:
> >>> Hi List,
> >>>
> >>> I found something, that looked promising, but did not work.
> >>> Developers, please look, this could be a bug:
> >>>
> >>> The deploy-task has an attribute "update", removes the context
> >>> before
> >>> re-installing it. I hoped that this one would do what I want.
> >>>
> >>> But unfortunately, it is equivalent to undeploy/deploy so my
> >>> sessions are gone
> >>> again. :-(
> >>>
> >>> Maybe I have to clarify, what I am doing with my sessions (for
> >>> Rodrigo):
> >>>
> >>> I have all session-attribute in my application serializable, so
> >>> that tomcat
> >>> can save all session data to disk when the context or tomcat
> >>> itself is
> >>> stopped.
> >>> At startup these serialized data is being read back by tomcat
> >>> automatically.
> >>> As a result, users can coutinue their work exactly where the are.
> >>> (Except that the application is not available for 1-2 seconds. But
> >>> it is still
> >>> unlikely that a users fires a request just in this moment, at least
> >>> for
> >>> medium-frequency apps)
> >>> Formerly, the persisted session data survived the remove, so I could
> >>> re-install the app.
> >>>
> >>> Please help!
> >>>
> >>> Reinhard
> >>>
> >>> Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosauer:
> >>>> Hello List,
> >>>>
> >>>> recently I upgraded from tomcat 5.5.9 to 5.5.15
> >>>> Since then, all my sessions are lost after a remove/install via the
> >>>> manager.
> >>>>
> >>>> The problem is the following:
> >>>> I installed a war-file, which is copied to the webapps-folder
> >>>> during
> >>>> manager-install. When I want to replace the war with a new
> >>>> version, I
> >>>> _have_ to undeploy, which deletes my persistent sessions too.
> >>>>
> >>>> How can I get back the smooth behavior of 5.5.9, which allowed
> >>>> me an
> >>>> application update on the fly without disturbing user sessions?
> >>>>
> >>>> many thanks in advance for your advice
> >>>>
> >>>> Reinhard
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
