Re: Silent runtime replace of a class
Thanky you very much, for your long answer. It seems, your theory is absolutely correct, I even found an article with detailed information about setting up a high availability Tomcat; here it is: http://www.javaworld.com/javaworld/jw-12-2004/jw-1220-tomcat.html --robert Peter Crowther wrote: From: Gal Robert [mailto:[EMAIL PROTECTED] Often happens, that we must correct a little error in business logic. In these cases we usually patch a class file, and replace it in the application, then redeploy it. From your (and other) responses it seems, there's no correct way to do such a patch without redeploying the application. Unfortunately, I agree. On the other hand, your idea about tomcat clustering, and redirecting requests sounds quite interesting. I think, this would satisfy the above requirement. Can you give me some more information about your idea? Does it require a deep know-how? Not really, but it requires that your application has a certain feature: that users using the application are independent, or that they only interact through a common back-end system that is not part of the webapp. A bulletin board is a reasonable example: users can post, and the posts are stored in a common database. Each user accesses posts through the webapp. It wouldn't matter if each user had their own separate webapp accessing the posts; nothing would appear to change. Many applications have this feature; yours may well. By contrast, an interactive chat system that uses (say) a Map in the context to know who's online doesn't have this feature - if you separate it across two servers, each would only see half the users. The multiple-server, staged upgrade is a standard technique in high-availability systems, where you want to have more than one of everything for redundancy. I'm adapting it a little here, to fulfil your requirement of on-the-fly upgrades. No doubt others on this list can fill in more details. I should add a disclaimer: I've done this with credit-card processing systems, but not with Tomcat, so I'm speaking from theory. The above should be taken with a large pinch of NaCl until someone corroborates it for Tomcat. That said, search the archives for this list, as I recall a couple of discussions from people who had almost exactly this setup. If you have n identical nodes and a way of shifting the load away from one of them, you can produce an idle node - at which point you can upgrade it to the new version. This part requires no more than several identical Tomcat (or other servlet container) instances. For high availability, you'd run them on different machines. For high flexibility and to allow upgrades (your situation), you could choose to combine them onto one machine if you wished to take the reliability risk and understood the performance characteristics of the system. Often, it's cheaper for the business to buy another pizza-box server and shove it in the rack than it is to pay someone's time to investigate the 'cheaper' way of doing it! The new part is that you need a front-end load balancer. This can be done in hardware (Cisco's mid- and high-end routers have this facility, for example). I strongly suspect it can also be done in software; I'd be very surprised if nobody had written this into some combination of Linux kernel and modules. I don't know whether it can be done using an Apache front-end and JK; I suspect someone on this list could enlighten us. The load balancer sits 'in front of' your n identical nodes and has its own IP address, which is the IP address by which your users connect to the application. That load balancer then redirects requests to the nodes according to its policy. That policy needs to include 'sticky' sessions: a set of requests from a given user will always be directed to the same node. If your organisation has no experience of setting one of these up, you'd probably want to buy in the expertise. Now, to upgrade a node (say node B of two nodes labelled A and B), you change the load balancer's policy: existing sessions remain sticky, but all new sessions go to node A. Monitor the number of sessions on node B; when it drops to zero, it's safe to upgrade B, restart it and test it - you know that no users will come in and disturb your tests. Then change load balancer policy to send new sessions to node B, wait for all the sessions on A to complete, and do the symmetrical upgrade on A. Finally, set your load balancer policy back to even distribution if you wish to use the redundancy in this system. You can short-circuit the whole process if you don't want the redundancy: the load balancer always directs traffic to one 'current' node, and most of the time you have one 'spare' node. To upgrade, make the change on the 'spare' node and test, then change policy to make the 'spare' node receive all new sessions. Once all the sessions have finished on the old 'active' node, the roles reverse - you have a new 'active' node that's been
RE: Silent runtime replace of a class
From: Gal Robert [mailto:[EMAIL PROTECTED] Thanky you very much, for your long answer. No problem. It seems, your theory is absolutely correct, I even found an article with detailed information about setting up a high availability Tomcat; here it is: http://www.javaworld.com/javaworld/jw-12-2004/jw-1220-tomcat.html Heh. Thanks, that's now added to my bookmarks! - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Silent runtime replace of a class
From: Gal Robert [mailto:[EMAIL PROTECTED] Often happens, that we must correct a little error in business logic. In these cases we usually patch a class file, and replace it in the application, then redeploy it. From your (and other) responses it seems, there's no correct way to do such a patch without redeploying the application. Unfortunately, I agree. On the other hand, your idea about tomcat clustering, and redirecting requests sounds quite interesting. I think, this would satisfy the above requirement. Can you give me some more information about your idea? Does it require a deep know-how? Not really, but it requires that your application has a certain feature: that users using the application are independent, or that they only interact through a common back-end system that is not part of the webapp. A bulletin board is a reasonable example: users can post, and the posts are stored in a common database. Each user accesses posts through the webapp. It wouldn't matter if each user had their own separate webapp accessing the posts; nothing would appear to change. Many applications have this feature; yours may well. By contrast, an interactive chat system that uses (say) a Map in the context to know who's online doesn't have this feature - if you separate it across two servers, each would only see half the users. The multiple-server, staged upgrade is a standard technique in high-availability systems, where you want to have more than one of everything for redundancy. I'm adapting it a little here, to fulfil your requirement of on-the-fly upgrades. No doubt others on this list can fill in more details. I should add a disclaimer: I've done this with credit-card processing systems, but not with Tomcat, so I'm speaking from theory. The above should be taken with a large pinch of NaCl until someone corroborates it for Tomcat. That said, search the archives for this list, as I recall a couple of discussions from people who had almost exactly this setup. If you have n identical nodes and a way of shifting the load away from one of them, you can produce an idle node - at which point you can upgrade it to the new version. This part requires no more than several identical Tomcat (or other servlet container) instances. For high availability, you'd run them on different machines. For high flexibility and to allow upgrades (your situation), you could choose to combine them onto one machine if you wished to take the reliability risk and understood the performance characteristics of the system. Often, it's cheaper for the business to buy another pizza-box server and shove it in the rack than it is to pay someone's time to investigate the 'cheaper' way of doing it! The new part is that you need a front-end load balancer. This can be done in hardware (Cisco's mid- and high-end routers have this facility, for example). I strongly suspect it can also be done in software; I'd be very surprised if nobody had written this into some combination of Linux kernel and modules. I don't know whether it can be done using an Apache front-end and JK; I suspect someone on this list could enlighten us. The load balancer sits 'in front of' your n identical nodes and has its own IP address, which is the IP address by which your users connect to the application. That load balancer then redirects requests to the nodes according to its policy. That policy needs to include 'sticky' sessions: a set of requests from a given user will always be directed to the same node. If your organisation has no experience of setting one of these up, you'd probably want to buy in the expertise. Now, to upgrade a node (say node B of two nodes labelled A and B), you change the load balancer's policy: existing sessions remain sticky, but all new sessions go to node A. Monitor the number of sessions on node B; when it drops to zero, it's safe to upgrade B, restart it and test it - you know that no users will come in and disturb your tests. Then change load balancer policy to send new sessions to node B, wait for all the sessions on A to complete, and do the symmetrical upgrade on A. Finally, set your load balancer policy back to even distribution if you wish to use the redundancy in this system. You can short-circuit the whole process if you don't want the redundancy: the load balancer always directs traffic to one 'current' node, and most of the time you have one 'spare' node. To upgrade, make the change on the 'spare' node and test, then change policy to make the 'spare' node receive all new sessions. Once all the sessions have finished on the old 'active' node, the roles reverse - you have a new 'active' node that's been upgraded, and the 'spare' running the prior version of the software. - Peter -- Peter Crowther, Director, Melandra Limited John Dalton House, 121 Deansgate, Manchester M3 2AB t: +44 (0)161 828 8736 f: +44 (0)161 832 5683
Re: Silent runtime replace of a class
This is tricky. Concerning jsp, you can simply replace old jsp with new one, they'll get recompiled. But what do you mean by replacing a class without affecting user work? This is practically impossible to do, because you can't change the class of an existing instance, all you can do is load new instances with the new .class. Howevr that mean datas saved in sessions and the new class will indeed be different (so things like (MyClass)session.get(someKey), will fail because someKey is of the old type. If what you want is redeploy a war without restarting tomcat, no problem, tomcat doens only restart the redeployed webapp. Le Mardi 5 Juillet 2005 14:21, Gal Robert a écrit : Hi, we have a new user requriement: to be able to modifiy the application without affecting user work. Is there any way to achieve this under tomcat? Currently we're building war file. Is there any way to replace a class (maybe jsp class) runtime, without restarting the tomcat? any information is welcome thanks. robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Silent runtime replace of a class
--- Gal Robert [EMAIL PROTECTED] wrote: Hi, we have a new user requriement: to be able to modifiy the application without affecting user work. Is there any way to achieve this under tomcat? Currently we're building war file. Is there any way to replace a class (maybe jsp class) runtime, without restarting the tomcat? any information is welcome JSPs are recompiled and reloaded when ever the JSP source file is changed. If you have other .class files such (including servlets), then you need to create a context.xml as per the documentation provided at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html You'll could place the context.xml in either the conf directory, or in the war's WEB-INF folder. Just ensure that the reloadable attribute is set to true. Since you've not specified which Tomcat version you're using, I've pointed you to the latest Tomcat 5.5 documentation. thanks. robert -- Sriram Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Silent runtime replace of a class
From: Sriram N [mailto:[EMAIL PROTECTED] --- Gal Robert [EMAIL PROTECTED] wrote: we have a new user requriement: to be able to modifiy the application without affecting user work. That's a very broad requirement, and may not be achievable in its full form. Does this mean that users must be able to continue working while a new version is deployed, unaware that a new version is being deployed under their feet, keeping all session context and so on? If so, I think you're onto a loser unless you can cluster your Tomcat instances - at which point you can point all your users to one of your instances (call it instance1) until there are none on instance2, upgrade instance2, point new users to instance2 until there are none on instance1, upgrade instance1, then go back to using both instances if you wish. This requires other software or hardware to keep track of which user sessions are using which instance. You'll could place the context.xml in either the conf directory, or in the war's WEB-INF folder. Just ensure that the reloadable attribute is set to true. Note that reloading a webapp when you have made changes may not allow the user to continue working - for example, if you've changed what's in the session then they may get errors. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Silent runtime replace of a class
--- Peter Crowther [EMAIL PROTECTED] wrote: From: Sriram N [mailto:[EMAIL PROTECTED] --- Gal Robert [EMAIL PROTECTED] wrote: we have a new user requriement: to be able to modifiy the application without affecting user work. snip/ You'll could place the context.xml in either the conf directory, or in the war's WEB-INF folder. Just ensure that the reloadable attribute is set to true. Note that reloading a webapp when you have made changes may not allow the user to continue working - for example, if you've changed what's in the session then they may get errors. Indeed. For e.g., if you've some objects in the session, and the web app is being reloaded, then active sessions would be serialized (along with the objects within them). Once the web app is reloaded completely and the sessions are reactivated, you may face problems in case you've changed the classes of those objects that were serialized within the session. - Peter -- Sriram __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Silent runtime replace of a class
I'll give you the user- requirement, to understand better the problem: pre-defined subsystems or modules should be upgraded or patched without interfering/interrupting system usage (defined by the supplier). Often happens, that we must correct a little error in business logic. In these cases we usually patch a class file, and replace it in the application, then redeploy it. From your (and other) responses it seems, there's no correct way to do such a patch without redeploying the application. On the other hand, your idea about tomcat clustering, and redirecting requests sounds quite interesting. I think, this would satisfy the above requirement. Can you give me some more information about your idea? Does it require a deep know-how? thank you and others Peter Crowther wrote: From: Sriram N [mailto:[EMAIL PROTECTED] --- Gal Robert [EMAIL PROTECTED] wrote: we have a new user requriement: to be able to modifiy the application without affecting user work. That's a very broad requirement, and may not be achievable in its full form. Does this mean that users must be able to continue working while a new version is deployed, unaware that a new version is being deployed under their feet, keeping all session context and so on? If so, I think you're onto a loser unless you can cluster your Tomcat instances - at which point you can point all your users to one of your instances (call it instance1) until there are none on instance2, upgrade instance2, point new users to instance2 until there are none on instance1, upgrade instance1, then go back to using both instances if you wish. This requires other software or hardware to keep track of which user sessions are using which instance. You'll could place the context.xml in either the conf directory, or in the war's WEB-INF folder. Just ensure that the reloadable attribute is set to true. Note that reloading a webapp when you have made changes may not allow the user to continue working - for example, if you've changed what's in the session then they may get errors. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Silent runtime replace of a class
This article may help... http://www.fawcette.com/javapro/2002_09/magazine/columns/proshop/ Gal Robert wrote: Hi, we have a new user requriement: to be able to modifiy the application without affecting user work. Is there any way to achieve this under tomcat? Currently we're building war file. Is there any way to replace a class (maybe jsp class) runtime, without restarting the tomcat? any information is welcome thanks. robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
