Re: Updating webapps classes
Hi, again on this subjetc, I discovered that Resin has this feature: http://www.caucho.com/resin/admin/deploy.xtp#web-app%20versioning I think this would be a very nice feature of Tomcat, don't you think? Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY http://www.sonicle.com -- Da: Christopher Schultz A: Tomcat Users List Data: 9 luglio 2010 3.01.37 CEST Oggetto: Re: Updating webapps classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabriele, On 7/7/2010 8:11 AM, Gabriele Bulfon wrote: I get back to this discussion beacuse I was brainstorming again on it, and found that the already present class loader may actually be able to do this alone. My thought was: if Tomcat is capable of managing different application contexts under its work folder, and have them run different applications with different class versions inside their classes/lib, probably it may implement automatic application updates by createing different application contexts behind the scene. Uh, what? I see this scenario: - Tomcat is running my webapp - People have sessions on it, and Tomcat has its application context on my webapp - I place new jar files/classes - Tomcat detects, and instead of reloading and invalidating current sessions, it will keep current sessions on the old application context, until they reach 0 sessions - Meanwhile it may create a new application context to run new sessions That's not how it works. How hard would it be to make this true in Tomcat? Probably not too difficult, but the Tomcat team is unlikely to implement this because the spec (at least as of 2.5) is silent on the subject of auto-deployment (other than to mention that the container is free to implement it). Such a system would be quite chaotic in a clustered environment, because some cluster members would update before others, and, depending upon the configuration of the cluster, information sharing and/or member selection could fail and the whole site could become unstable from a user perspective. I highly recommend performing deliberate application updates by bleeding users off of one server and on to another. Is there any other Java WebApp Container capable of doing this? Dunno. You could probably search the web for something like that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw2dPEACgkQ9CaO5/Lv0PBTXwCgpTZ9b5rEYImtsRV0cGfbKaN+ 4AMAoIjrUIaVDlw+0Xu1c/BJHd5cAjvW =eeFX -END PGP SIGNATURE- - 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: Updating webapps classes
Hello, thx for your answers. I understand your points, but in a non cluster situation, updating the application is a pain, because I'm forced to ask people to exit, update and restart. It may be a possible option to do what I said, and would be my responsability to know if an update may lead to problems because of possible concurrent usage of old and new version. What do you think? Gabriele. Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY http://www.sonicle.com -= Mail sent through WebTop2 =- -- Da: Christopher Schultz A: Tomcat Users List Data: 9 luglio 2010 3.01.37 CEST Oggetto: Re: Updating webapps classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabriele, On 7/7/2010 8:11 AM, Gabriele Bulfon wrote: I get back to this discussion beacuse I was brainstorming again on it, and found that the already present class loader may actually be able to do this alone. My thought was: if Tomcat is capable of managing different application contexts under its work folder, and have them run different applications with different class versions inside their classes/lib, probably it may implement automatic application updates by createing different application contexts behind the scene. Uh, what? I see this scenario: - Tomcat is running my webapp - People have sessions on it, and Tomcat has its application context on my webapp - I place new jar files/classes - Tomcat detects, and instead of reloading and invalidating current sessions, it will keep current sessions on the old application context, until they reach 0 sessions - Meanwhile it may create a new application context to run new sessions That's not how it works. How hard would it be to make this true in Tomcat? Probably not too difficult, but the Tomcat team is unlikely to implement this because the spec (at least as of 2.5) is silent on the subject of auto-deployment (other than to mention that the container is free to implement it). Such a system would be quite chaotic in a clustered environment, because some cluster members would update before others, and, depending upon the configuration of the cluster, information sharing and/or member selection could fail and the whole site could become unstable from a user perspective. I highly recommend performing deliberate application updates by bleeding users off of one server and on to another. Is there any other Java WebApp Container capable of doing this? Dunno. You could probably search the web for something like that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw2dPEACgkQ9CaO5/Lv0PBTXwCgpTZ9b5rEYImtsRV0cGfbKaN+ 4AMAoIjrUIaVDlw+0Xu1c/BJHd5cAjvW =eeFX -END PGP SIGNATURE- - 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: Updating webapps classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabriele, On 7/7/2010 8:11 AM, Gabriele Bulfon wrote: I get back to this discussion beacuse I was brainstorming again on it, and found that the already present class loader may actually be able to do this alone. My thought was: if Tomcat is capable of managing different application contexts under its work folder, and have them run different applications with different class versions inside their classes/lib, probably it may implement automatic application updates by createing different application contexts behind the scene. Uh, what? I see this scenario: - Tomcat is running my webapp - People have sessions on it, and Tomcat has its application context on my webapp - I place new jar files/classes - Tomcat detects, and instead of reloading and invalidating current sessions, it will keep current sessions on the old application context, until they reach 0 sessions - Meanwhile it may create a new application context to run new sessions That's not how it works. How hard would it be to make this true in Tomcat? Probably not too difficult, but the Tomcat team is unlikely to implement this because the spec (at least as of 2.5) is silent on the subject of auto-deployment (other than to mention that the container is free to implement it). Such a system would be quite chaotic in a clustered environment, because some cluster members would update before others, and, depending upon the configuration of the cluster, information sharing and/or member selection could fail and the whole site could become unstable from a user perspective. I highly recommend performing deliberate application updates by bleeding users off of one server and on to another. Is there any other Java WebApp Container capable of doing this? Dunno. You could probably search the web for something like that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw2dPEACgkQ9CaO5/Lv0PBTXwCgpTZ9b5rEYImtsRV0cGfbKaN+ 4AMAoIjrUIaVDlw+0Xu1c/BJHd5cAjvW =eeFX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Updating webapps classes
I get back to this discussion beacuse I was brainstorming again on it, and found that the already present class loader may actually be able to do this alone. My thought was: if Tomcat is capable of managing different application contexts under its work folder, and have them run different applications with different class versions inside their classes/lib, probably it may implement automatic application updates by createing different application contexts behind the scene. I see this scenario: - Tomcat is running my webapp - People have sessions on it, and Tomcat has its application context on my webapp - I place new jar files/classes - Tomcat detects, and instead of reloading and invalidating current sessions, it will keep current sessions on the old application context, until they reach 0 sessions - Meanwhile it may create a new application context to run new sessions How hard would it be to make this true in Tomcat? Is there any other Java WebApp Container capable of doing this? Gabriele. Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY http://www.sonicle.com -- Da: Christopher Schultz A: Tomcat Users List Data: 3 maggio 2010 15.57.57 CEST Oggetto: Re: Updating webapps classes -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, On 4/30/2010 10:33 AM, Peter Crowther wrote: In normal use, Tomcat1 is running. The load balancer directs all users to Tomcat1. Tomcat2 could even be stopped. I would say that normal use would include both (or however many) instances running in parallel. When it's time to upgrade, you mark one or more nodes in the cluster as don't send any new users to this node and wait for all the users on those nodes to complete their work. After that, Peter's scenario is exactly the same. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkve1mUACgkQ9CaO5/Lv0PAOhgCfRCZLdT0flr3es5Oc5IpCCNNl bokAn1F22eum4C6vhHoEv2LjQXee/9uk =IpQb -END PGP SIGNATURE- - 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: Updating webapps classes
Hi, thanx for the interesting solution. Anyway, not always possible to run 2 tomcat instances because of memory requirements. Do you see any different solution with 1 tomcat only (or tomcat + apache)? Thx in advance, Gabriele. Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY http://www.sonicle.com -- Da: Peter Crowther A: Tomcat Users List Data: 30 aprile 2010 16.33.39 CEST Oggetto: Re: Updating webapps classes It's very hard to do this using one Tomcat instance. It's very easy to do this using two Tomcat instances (call them Tomcat1 and Tomcat2) and a load balancer (Apache httpd should be fine for this job). In normal use, Tomcat1 is running. The load balancer directs all users to Tomcat1. Tomcat2 could even be stopped. To upgrade, you upgrade Tomcat2 (and start it if needed) and tell the load balancer that new sessions should be sent to Tomcat2. Once all user sessions are off Tomcat1, you upgrade it and tell the load balancer to direct new sessions to Tomcat1. Once all user sessions are off Tomcat2, you can shut it down again or leave it running for fault tolerance. If you have enough RAM on your server (and the load is low enough), you could even run all three of Tomcat1, Tomcat2 and httpd on the same server. Does this help? - Peter On 30 April 2010 14:46, Gabriele Bulfon wrote: Hello, I don't know if I'm asking something stupid, but I'm investigating this for days, and found nothing around. Updating a java webapp can be a problem when this java webapp is being ised 24/7 by users, and many of them have sessions running for all the working hours. Consider that this webapp consists of many instance classes being created during session startup. How can I manage updates of the webapp classes without having to reload the webapp? What I would like is that users inside the application to continue to see the old version, while new ones logging in would see the latest one. I don't know if there is any way for this Thanks Gabriele. - 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: Updating webapps classes
Gabriele Bulfon wrote: Hi, thanx for the interesting solution. Anyway, not always possible to run 2 tomcat instances because of memory requirements. Do you see any different solution with 1 tomcat only (or tomcat + apache)? Gabriele, I think Peter gave you the only appropriate general answer. You could imagine a scheme whereby - you have under Tomcat 2 versions of your webapp (say /webappA and /webappB), of which only one is the active one at any particular time - your users access the application by a URL like /XYZ/.. - the front-end Apache, by using something like mod_rewrite, would rewrite such URLs to either /webappA or /webappB, before forwarding them to Tomcat. Say that for the moment the active one is webappA, and the Apache front-end rewrites /XYZ to /webappA. - then you update webappB - then you change the Apache rewrite rule to rewrite /XYZ to /webappB, and reload Apache (not restart, reload) - then you can update webappA ... BUT, how your Tomcat applications and the ongoing user sessions in them will react to this, only you can tell, knowing your application and what kind of change you make from one version to the next. Clearly, if a change involves changing the content of what is stored in a session, or the forms you are sending to the browsers (*), you would be in trouble. My knowledge of Java and Tomcat is too limited to know what other kind of trouble you may be in, but I can imagine it may be plenty. It may work, if every HTTP request to Tomcat is really independent of any previous one, and you do not use sessions. Peter's solution is the real solid one. Memory requirements can be solved nowadays for very little money. The time you would spend designing and debugging a scheme like the above would be many times more expensive. (*) example : - webappA sends a form to a browser, with input fields a,b,c,d. - you update webappB, and now the form has fields a,b,c,d,e, and webappB expects that - now you switch webappB for webappA - then the user submits the form, still with fields a,b,c,d. But this submit goes to webappB now. Does webappB survive ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Updating webapps classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, On 4/30/2010 10:33 AM, Peter Crowther wrote: In normal use, Tomcat1 is running. The load balancer directs all users to Tomcat1. Tomcat2 could even be stopped. I would say that normal use would include both (or however many) instances running in parallel. When it's time to upgrade, you mark one or more nodes in the cluster as don't send any new users to this node and wait for all the users on those nodes to complete their work. After that, Peter's scenario is exactly the same. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkve1mUACgkQ9CaO5/Lv0PAOhgCfRCZLdT0flr3es5Oc5IpCCNNl bokAn1F22eum4C6vhHoEv2LjQXee/9uk =IpQb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Updating webapps classes
Hello, I don't know if I'm asking something stupid, but I'm investigating this for days, and found nothing around. Updating a java webapp can be a problem when this java webapp is being ised 24/7 by users, and many of them have sessions running for all the working hours. Consider that this webapp consists of many instance classes being created during session startup. How can I manage updates of the webapp classes without having to reload the webapp? What I would like is that users inside the application to continue to see the old version, while new ones logging in would see the latest one. I don't know if there is any way for this Thanks Gabriele. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Updating webapps classes
It's very hard to do this using one Tomcat instance. It's very easy to do this using two Tomcat instances (call them Tomcat1 and Tomcat2) and a load balancer (Apache httpd should be fine for this job). In normal use, Tomcat1 is running. The load balancer directs all users to Tomcat1. Tomcat2 could even be stopped. To upgrade, you upgrade Tomcat2 (and start it if needed) and tell the load balancer that new sessions should be sent to Tomcat2. Once all user sessions are off Tomcat1, you upgrade it and tell the load balancer to direct new sessions to Tomcat1. Once all user sessions are off Tomcat2, you can shut it down again or leave it running for fault tolerance. If you have enough RAM on your server (and the load is low enough), you could even run all three of Tomcat1, Tomcat2 and httpd on the same server. Does this help? - Peter On 30 April 2010 14:46, Gabriele Bulfon gbul...@sonicle.com wrote: Hello, I don't know if I'm asking something stupid, but I'm investigating this for days, and found nothing around. Updating a java webapp can be a problem when this java webapp is being ised 24/7 by users, and many of them have sessions running for all the working hours. Consider that this webapp consists of many instance classes being created during session startup. How can I manage updates of the webapp classes without having to reload the webapp? What I would like is that users inside the application to continue to see the old version, while new ones logging in would see the latest one. I don't know if there is any way for this Thanks Gabriele. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
