Am 27.03.2017 um 09:30 schrieb Joan Tomàs i Buliart: > Hello, > > We currently deploy our JSPs outside of the WAR. This allows us to > deploy the main application container and the JSP views at different > pace (one team moves much faster than the other). In order to support > this, we have JSPs out of the war. When the webapp is deployed some > soft-links are created to the folders the JSPs are. Finally, when we > deploy new/updated JSPs, the JspServlet detects it, recompiles the > new/updated JSPs and replaces the classes. > > This workflow works fine when the changes are little and the servers > load average is low. The problem comes when a developer modifies one > of the main JSPs or the load of the servers is high. In this > situation, all the servers starts to compile the updated JSP and, due > to the amount of load, lots of request end up throwing 504 errors. > > We are considering to pre-compile the JSPs before deploying them to > the server. The problem is that we are not able to find any option to > force Tomcat to hot reload ONLY the updated classes. All the different > reload options that we have tested end up reloading all the webapp > (which means 80s of downtime for us). > > Is there any recommended option to manage this? Does somebody have a > similar scenario or a suitable solution? > Joan Tomàs,
You're asking for a workaround to a workaround that you've configured - i.e. your deployment strategy is quite unusual, and you're finding the setbacks. For tomcat, a web application is the unit of deployment, and the basic behaviour is to not expect sudden changes. In fact, to most people I do recommend to keep proper procedures, e.g. for disaster recovery, to fully automatically deploy everything, all the time. The production settings at https://tomcat.apache.org/tomcat-8.5-doc/jasper-howto.html say > "The main JSP optimization which can be done is precompilation of JSPs. However, this might not be possible (for example, when using the jsp-property-group feature) or practical, in which case the configuration of the Jasper servlet becomes critical." That being said, you have 80s downtime when redeploying the web application, which makes it impractical to do precompilation of JSPs (the way that Jasper was designed). To me, not accepting 80s downtime implies that you are already running a cluster, and you might be happy with rolling updates - e.g. take one machine out of your loadbalancer's rotation, update it, (optionally warm up caches) and introduce it again. If you have sticky sessions, it might take an hour or three until most sessions have timed out, but fully automated, you can be sure that sooner or later your JSPs are updated - not all at the same time though. This strategy might even allow you to keep your current workaround up, as it only implies the update to be done while the server doesn't get any request to serve. It does not imply a full redeploy of the application (though that would be my default) Other options that I can envision is to change Jasper's implementation to keep serving a compiled JSP until the replacement has been properly compiled and loaded in the background (e.g. not having compilation block further requests to the same page). I haven't looked at the implementation though and don't know a) if it's feasible and b) if you like to dive that deep into the code to change tomcat's implementation. Olaf --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
