On 23/02/12 7:24 PM, Mark Thomas wrote:
On 23/02/2012 06:51, Aristedes Maniatis wrote:
We've been using parallel deployment for some time now with tomcat
7.0.25. For the most part the parallel deployment is a really nice idea,
particularly because we don't have sessions serialised and clustered
across all running instances.
However, we've had mysterious problems for some time now where fixes
we've applied to the application don't seem to work. We added some
logging and have confirmed that some requests are still being served by
the OLD instances of the application which are still deployed in the
tomcat container but have an older version and therefore should not be
responding. We might have two apps like this (using a format of YYMMDD
and a two digit sequence):
enrol##12022203.war
enrol##12021503.war
We would expect that requests would be served from only the newer
application, but we find that requests continue to be served from the
old, even though all the sessions to the old application are long dead.
Just to confirm things we have another application which does not use
sessions at all. It also has the same problem: requests are being served
by the wrong application.
In Tomcat Manager, the old application is still marked as running, but
we thought this is just how it appears in the UI. Clearly there is
something not right here.
1. Is this a known issue?
We'd need to understand the root cause to answer that. The short version
is that requests will only be routed to the old version if a request
includes a session ID that references it. I'd suggest adding the session
cookie to your access log.
Given that we've definitely seen this happen with our sessionless application,
I'm not sure that will help us much. For our other apps which have sessions,
what happens if the incoming cookie references a session which has expired?
Will the connection be simply handled by the new application? Is there some
chance that the old application then creates a new valid session for that
connection?
What we did do is add a version to our log4j logger so that we could see which
application was handling requests. We got quite a mixture of requests to the
older sessionless application.
2. Is there some way to get the old application to fully undeploy as
soon as it has no live sessions?
No. It is on the to do list.
Is there a task I can follow? I was unable to find one.
We have been thinking about writing an
external application to poll using JMX and do this, but that's quite a
bit of work. It would be nicer if this happened inside tomcat itself.
Agreed. Patches welcome.
Sure. I understand, but I would not know where to begin with the tomcat
codebase. I haven't even tried to read the source at this point. I assume we'd
need to hook into some listener that detects when sessions are terminated and
tell when they reach zero. That is maybe one line of code in the right place...
or not :-)
3. Is there some resource we might be hanging onto which is preventing
the old application from properly stopping?
Maybe. But that would be a separate issue.
I am just looking for solutions within the particular stack that we are using
(tapestry/cayenne) to see if there was some reason why tomcat wasn't fully
letting go of the older application.
4. Should the tomcat manager show the older apps as still running or
should they be shown as stopped?
running.
It would be nice if it showed as "disabled" (to use the mod_jk terminology for
an instance which is running but gets no new sessions). But that doesn't really affect
our underlying problem: it would just make it easier to understand what is happening.
Thanks for your time.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
