Re: Tomcat vs Jboss-Tomcat
I think, this is not realy about Tomcat nor Jboss-tomcat. You should consider about clustering (run more instances of your web server to handle requests simultaneously). You can achieve this quite easily with multiple tomcats+some hardware load balancer Sridhar wrote: Hi, Tomcat is better for the JSPs, But my main problem is my server able to handle 2000+ requests per second.So which is better one Web Server or Application Server. Rgds Sridhar - Original Message - From: Raghupathy,Gurumoorthy [EMAIL PROTECTED] To: 'Tomcat Users List' tomcat-user@jakarta.apache.org Sent: Tuesday, July 19, 2005 3:54 PM Subject: RE: Tomcat vs Jboss-Tomcat For only jsp use tomcat ... More easy to configure and run -Original Message- From: ohaya [mailto:[EMAIL PROTECTED] Sent: 19 July 2005 10:57 To: Tomcat Users List Subject: Re: Tomcat vs Jboss-Tomcat Sridhar, For just JSPs, you only need Tomcat. I think that JBoss will be needed if you use EJBs. Jim Sridhar wrote: Hi Everybody, Is it any difference will come between Tomcat and Jboss-Tomcat. Which is best for Executing executing only JSPs. Regards Sridhar - 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] - 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]
Do I need 2 clusters for upgrades with fail-over?
Hi, this thread refers to 'Silent runtime replace of a class' thread. We need to provide application upgrades, where users work won't be interrupted. We also need fail-over future for application, meaning, if one of the appservers goes down, users won't lost their work. We need the simplest solution, but since we don't have any experience with fail-over future, we'd like to find out the simplest solution by your help. We've read some documents and designed solution with these components: 1) front-end software-based load balancer (probably tomcat with the balancer webapp). 2) main cluster A with two tomcat instances 3) offline spare cluster B with two tomcat instances The whole configuration is on a single machine. The upgrade scenario will look like this: 1) bring up, deploy and test the new application on the spare cluster 2) modify the load balancer policy to redirect new user sessions to the spare cluster (with upgraded app) So all the new sessions will run on the upgraded cluster. After the number of active users on the main cluster drops to zero, it's safe to stop it; so the roles of cluster will change. To ensure fail-over future, in-memory session replication will be enabled. The main reason to divide the system into two cluster is because of the fail-over future, more precisiously the session replication. If there will be only one cluster, the session replication won't work correctly between the upgraded/old app. Do you agree? Do you have any recommendations/ideas for a simpler setup with upgrade/fail-over futures? Any ideas, points to articles is welcomme! --robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Silent runtime replace of a class
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]
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]
