opksurf.blogg.se - Why apache tomcat 8 is not showing in preferences

wait for tomcat2 to come up, sanity test the application yourself!.

wait until all connections are hitting tomcat1 (use jmx or netstat to monitor network connections).

(haproxy definitely and I think mod_proxy allow you to change the instance preference live.)

change tomcat2 preference level in the server-farm in the load balancer to zero.

The simplest way, is to have a front-end load balancer such as apache, haproxy, or Cisco CSM with 2 or more tomcat instances - where the load balancer supports sticky sessions and hot load balancer configuration deployment. (There are a number of caveats to these approaches which I will cover below.) Hence to allow the transparent end-user experience you are going to need to have 2 versions of your app running at the same time for a short period, one for the old connections and one for the new.

It's not very transparent, and you end up serving horrible 500 errors until the app is back on its feet :-( Unfortunately, with tomcat if autodeploy=true is set, any change to the configuration files or war contents causes a rather ungraceful redeployment of the Context and I would guess the Catalina web container waits for some specified time, before killing all the outstanding threads and requests.

There are effectively 2 versions of the application running during the graceful restart transition managed by apache, the old and the new. Hence long running connections can finish downloading while new requests get the new content.

apache's graceful restart advises its children to exit after their current request has completed, and replaces them with new spawned processes/threads that have re-read the new configuration file. Given that tomcat frequently takes 30 seconds or more depending on how monstrous and bloated your application is to deploy from cold, it is usually useful to be able to do it transparently.Īn additional bonus of this method I will explain is that it is reassuring to be able to check the new application in production before putting it live to your customers. With respect to the other answers correct description of tomcat as an application server vs httpd and the associated issues there are actually a number of ways to get what you want, which is an end-user transparent restart. If you have load balanced tomcat instances and your load balancer supports sticky sessions and live configuration, then the you can achieve the kind of rolling and transparent upgrades that you are talking about (to some degree) by rotating out the tomcat instances 1 by 1.