Re: reload vs restart

[Christopher Schultz <ch...@christopherschultz.net>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: reload vs restart

[Rob Sargent <rs...@xmission.com>]

Chris,


> On Mar 2, 2021, at 9:46 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 
> 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.
> 
Pretty sure I’ll just be careful about how and when I add new customers.  I’m not nearly clever enough to properly implement anything more sophisticated.

Cheers,
rjs