We run several instances of Tomcat to keep users from affecting each other. For example, since each Tomcat is a different process, if one app loaded in one of the Tomcat instances has a problem, we can bring that Tomcat instance down w/o affecting the others. Also, the likelihood that one application in a Tomcat process will affect an app in a different process is diminished since they are distinct.
Also, each process can be started with different permissions. For example, if there are a set of files (like digital certificates, etc), the different Tomcat instances will be prevented from -- at the OS level -- reading each other's files. Also, can start one of the Tomcat's up with a very limiting java.policy file that constrains what users can do in a webapp. The users are prohibited from calling <% System.exit(1) %>. You may also want several Tomcat's to test different configurations or have different configurations tuned to production vs. development. For example, in development you can limit the number of threads that a Connector uses since you aren't as concerned with # of concurrent users. ----- Original Message ----- From: Derek Clarkson <[EMAIL PROTECTED]> Date: Thursday, February 12, 2004 0:22 am Subject: RE: Multiple instances of Tomcat - why would you do it ? > He he, thanks. By the looks of the code I'm seeing - I'm going > with the > space bats reason ;-) > > -----Original Message----- > From: Josh Rehman [EMAIL PROTECTED] > Sent: Thursday, 12 February 2004 12:41 PM > To: Tomcat Users List > Subject: Re: Multiple instances of Tomcat - why would you do it ? > > If the instances talk to each other via RMI, it's likely that the > originaldevelopers intended each instance to be run on a different > box. > They may have thought this would positively affect scalability. > > It may also be that they partitioned the app such that each > container has > different priveledges and responsibilities, and therefore it made > sense to > seperate them and configure them seperately. > > It may also be that the original developer was testing a theory > and so did > it that way. > > It may also be that the developers were being paid per CPU. > > It may also be that one of the architects was driven mad by alien > spacebats, and so designed this system to prepare himself for > leaving this > planet. > > The last one seems most likely to me. However, I could be wrong, > so I'd ask > the original developer. > > Derek Clarkson wrote: > > Hello everyone, > > I've just started a new job where I've been asked to be the tech > lead > > on a project. The software originated from an external company > who > > designed it to run on 3 instances of tomcat. There is an > instance for > > the main applications for our customers, an instance for the > admin > > section and another for secure transactions. All running on the > same > > PC. These instances also communicate between each other in order > to > > pass information from one to the other via RMI. > > > > I've never worked on a mulit instance installation before and no- > one > > here knows why it was done this way (it's not documented). Can > you > > guys give me any thoughts on why a multi-instance might be setup > like > > this ? What are the advantages over a single tomcat instance, > etc ? > > > > Essentially I'm trying to understand whether this was a good > solution > > for our use. Understanding the sorts of reasons for doing it > will help > > me to work out any possible future changes. > > > > > > Ciao > > Derek. > > > > > > > ______________________________________________________________________> This email, > including attachments, is intended only for the addressee > > and may be confidential, privileged and subject to copyright. > If you > > have received this email in error, please advise the sender and > delete > > it. If you are not the intended recipient of this email, you > must not > > use, copy or disclose its content to anyone. You must not copy > or > > communicate to others content that is confidential or subject to > > copyright, unless you have the consent of the content owner. > > > > -- > Josh Rehman > citysearch.com > 213.739.3559 > > > ------------------------------------------------------------------- > -- > 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]
