Rob,
On 2/27/21 23:34, Rob Sargent wrote:
Chris,
Thank you, yet again.
On 2/26/21 9:31 PM, Christopher Schultz wrote:
Rob,
On 2/26/21 16:47, Rob Sargent wrote:
Given a single webapp, what's the difference between server restart
and webapp reload in terms of current open sessions?
That depends upon a few things.
If you do not have session-persistence enabled, then you will lose all
your sessions in either case.
If you do have session-persistence enabled, then reloading your
application will allow requests arriving for that application during
the restart to be accepted and wait for the application to become
available. If, instead, you restart your server (which means
stopping/starting the JVM, or at least stopping/starting all of the
Connectors in an embedded scenario), then there will be a period of
time where clients might receive any number of errors such as
"connection refused", etc.
I have not, far as I know, enabled session-persistence yet "persistent
sessions" are sought on starting the JVM so perhaps that's the default
mode.
I think that default was recently changed to DISABLE that persistence.
You may still have it enabled in your environment/version. Note that
this persistence will only work separately on each node, of course.
My worry is that I have some rather lengthy data transfers (streamed
from client to TC) and losing one of those would be a week's worth of
m5.4xlarge down the drain (unless and until I get the interim/fall-back
file save working on s3). So I'm wondering how circumspect I have to be
on this front. The only change to the running webapp would be a new db
resource in the context.xml and a ref to it in the web.xml. This harks
back to my "wildly successful" scenario wherein a second customer shows
up while the first is still running. Worst comes, I can simply delay
adding the new customer for a week. (Code changes to the webapp proper
would be done "between jobs". They get there own database.)
HA is certainly complicated by long-running jobs. If you don't want to
kill a running job, you will need to arrange to NOT take-down that node.
Bouncing Tomcat through the usual means (e.g. "catalina.sh stop" then
"catalina.sh start") will kill your JVM unless you have non-daemon
threads running (your own application would be doing this). In that
case, performing "catalina.sh stop" wouldn't actually stop the JVM. But
it would shut-down all the HTTP connections so even though the jon would
continue, the network connections would all be dropped. That may end up
having the same effect on your clients, depending upon how your
application works.
If you deploy another version of your application alongside the existing
one (aka "parallel deployment"), in-flight requests will still use the
old version of the application until they complete. In fact, any clients
using session-management (which I assume is ALL of them, given your
original post) will see the old version of the application until the
session is terminated and re-established. So log-out/log-in gets you the
new version. Effecrively, you get no downtime at all, but you may
require extra resources (memory) to have the application deployed twice
simultaneously.
If you are going embedded (which it sounds like you are from other
recent posts), are you also using a load-balancer and some kind of
clustering, management, etc? If so, you should be able to configure
your reverse-proxy/lb to ensure that Tomcat is actually available
before proxying requests to that node, or failing-over to another node.
If you want true high-availability, you will either want a shared
session-store (e.g. db, memcached, etc.) or clustering (using Tomcat's
clustering) in which case restart versus reload doesn't matter much.
No HA, no load balancing in play - not millions of hits, ever. In it's
previous incarnation the system used pg-bouncer for connection pooling
but I think I can live with the TC built-in.
So you just have a single Tomcat node? Yeah, you are going to want to
use parallel deployment unless you can be VERY careful about your JVM
restarts.
You will also need to familiarize yourself with using the Manager
application because IIRC old versions of the application will not
automatically stop and undeploy once their session-count goes to zero.
That means if you leave your server running for 1 month and deploy each
week, you'll end up with 4 (or 5) copies of the application in memory,
most of which are probably no longer used.
Login with the Manager to see which ones are no longer used and then
simply undeploy them to clean up.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
