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
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
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
