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.
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.)
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.
Cheers,
rjs
