Howdy, First off, the general questions, then your specific design issue: >servlet and/or filter context running within its own JVM instance? or >within its own Process (as in java.lang.Runtime.exec)? In other words, do >all servlets and filter contexts share the same JVM instance or are they >separated somehow?
- An instance of tomcat corresponds to a single JVM instance. - Each context has its own classloader within the JVM instance. See the servlet spec for classloading requirements and tomcat's classloader how-to page for details. >If they are kept separate, how (generally speaking) is >that being achieved? The servlet specification defines what servlet and filters can do with each other, e.g. request forwarding or inclusion, and what's kept separate, e.g. classes in the webapp's WEB-INF/lib directory. To see how tomcat specifically implements this, you will need to look through the tomcat source. The package org.apache.catalina[] is a good place to start. However, be very careful when relying on server-specific features/implementation. Your best bet as far as portability, including portability to future versions of tomcat, is to stick to the servlet specification. >contexts within the Tomcat container. If a servlet (say) decides to chew >up all of its available memory, will that choke the memory for the rest of >the servlets and filters in other contexts running on the server? or will >that only impact the rogue servlet itself? It will impacts all the contexts, ultimately causing a java.lang.OutOfMemoryError that will necessitate you to restart the server. >Specifically, I'm considering using a Filter to "hand off" the Input and >Output Streams of a request to a relatively large Object the Filter will >have instantiated. This Object is not a servlet, but a multi-threaded Jini >Service. Since there will be more than a few of these Filter-to-Jini >Service "bridges" running within the Tomcat container, I'd like to know >whether or not they will be in their own JVM instance. (If not, I suspect >I >may not want to do this.) Is it your own jinni service that you wrote, or a 3rd party? In either case, you want to ensure they can't consume all that memory. This can be exceedingly difficult. Another way to go is to determine that maximum size of this Object that you're willing to handle. This depends on how much memory you can allocate to the JVM. You may have to limit user inputs, and/or validate that the user's request won't result in an oversize object, before handing the streams over to this service. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
