Re: reload vs restart
Chris, > On Mar 2, 2021, at 9:46 AM, Christopher Schultz > 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
Re: reload vs restart
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
Re: reload vs restart
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
Re: reload vs restart
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. 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. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
reload vs restart
Given a single webapp, what's the difference between server restart and webapp reload in terms of current open sessions?
