Re: Hot pre-compiled JSP reloading
On 27/03/17 11:39, André Warnier (tomcat) wrote: On 27.03.2017 10:56, Mark Thomas wrote: On 27/03/17 09:26, Olaf Kock wrote: 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. a) is a solution I have just been thinking about. My initial impression is that while the simple case is probably do-able, once you start thinking about dependencies it could get very tricky, very fast. Probably a practical case of : https://en.wikipedia.org/wiki/No_free_lunch_theorem I'd suggest looking at deploying as a single WAR and using parallel deployment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org The main problem with the rolling deployment is that the JSP folder is a NFS shared along all the servers on the cluster, but we can manage some how. In the case that we decide to try to extend Jasper to do this, any clue on which is the appropriate hook to use? That is, which class modify? Many thanks in advance, Joan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hot pre-compiled JSP reloading
On 27.03.2017 10:56, Mark Thomas wrote: On 27/03/17 09:26, Olaf Kock wrote: 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. a) is a solution I have just been thinking about. My initial impression is that while the simple case is probably do-able, once you start thinking about dependencies it could get very tricky, very fast. Probably a practical case of : https://en.wikipedia.org/wiki/No_free_lunch_theorem I'd suggest looking at deploying as a single WAR and using parallel deployment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hot pre-compiled JSP reloading
On 27/03/17 09:26, Olaf Kock wrote: > 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. a) is a solution I have just been thinking about. My initial impression is that while the simple case is probably do-able, once you start thinking about dependencies it could get very tricky, very fast. I'd suggest looking at deploying as a single WAR and using parallel deployment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hot pre-compiled JSP reloading
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
Re: Hot pre-compiled JSP reloading
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? Hi. I cannot help you personally, and this will have to wait for a real expert. But thanks in any case for the clear and succint description of the issue, I am sure that will help you get some answers quickly. Maybe one additional information might help someone to help you : the precise version of Tomcat which this is related to (options may differ depending on the version). And while you're at it, throw in the platform and JVM too. Hi André, we are using Tomcat 8.0.12 with jvm 1.8.0_92 on Linux (aws and ubuntu). We are starting the migration to 8.5.12. Many thanks in advance, Tomàs - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hot pre-compiled JSP reloading
On 27.03.2017 09:30, Joan Tomàs i Buliart wrote: 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? Hi. I cannot help you personally, and this will have to wait for a real expert. But thanks in any case for the clear and succint description of the issue, I am sure that will help you get some answers quickly. Maybe one additional information might help someone to help you : the precise version of Tomcat which this is related to (options may differ depending on the version). And while you're at it, throw in the platform and JVM too. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Hot pre-compiled JSP reloading
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? Many thanks in advance, Joan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
