> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]