****ServletContext and WebApplication confusion****

[Amit Das]

Hi all,

The sevlet API says :

There is one context per "web application" per Java Virtual Machine. (A "web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file.)

It further says this also:

In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine

My confusion is :

1. Is it possible to have more than one web application in single Servlet Container???

2. What is a "distributed" web application? I mean can u gimme a scenario so that i can appreciate the concept???

3. Since the Server loads the JVM, which later runs the servlet container....right??? If yes, than why does the statement read "There is one context per "web application" per Java Virtual Machine."??
Does it mean that a sngle Web server can load more than one JVM and hence there will be more than one Servlet Container???

Plz, if anyone can clarify my doubts, I'd really grateful.

Thanks,
Amit

[Charles Lyons]

1. Is it possible to have more than one web application in single Servlet Container?

Yes, each application is identified by its unique "context root". You can't have two applications at the same context root as then the container wouldn't know which application to send requests to. However, you can use the same container for applications installed to www.mydomain.ext, sub.mydomain.ext etc. for all subdomains and any other domains you wish, and also for paths within those domains. For example you can have two different applications installed under the domain mysite.com, then you could have mappings to / and /forum in the same container each to different Web applications.

2. What is a "distributed" web application? I mean can u gimme a scenario so that i can appreciate the concept?

A distributed application is one which is deployed on several application servers simultaneously - picture several identical servers lined up side-by-side each with an identical copy of the Web application. Then requests from clients can be sent (or "farmed") to any one of those running applications. The advantage is only apparent in enterprises with high volumes of traffic; in this case the group of servers is referred to as a "cluster" and helps to perform "load balancing". This means that clients are not dependent on just one machine to do all the processing of the thousands of requests; instead you can delegate to a machine that's currently doing less work, and therefore improving response-serving times. Unless you work with high-volumes, with hundreds of simultaneous users and requests, this never becomes an issue.

3. Since the Server loads the JVM, which later runs the servlet container....right? If yes, than why does the statement read "There is one context per "web application" per Java Virtual Machine.? Does it mean that a sngle Web server can load more than one JVM and hence there will be more than one Servlet Container?

In general, J2EE Web servers (or just servlet containers like Tomcat) are built using Java... this means they are actually running inside their own JVM instance. Hence there is only one JVM running, and it is actually started before the server (so in this case, the server doesn't load the JVM - it's already running). However, if you have multiple servers (and therefore containers) then you will also have multiple JVMs. So the statement "This is one context per Web application per JVM" essentially reduces to the statement that each application in a single container has only one context associated with it (indeed the converse that "each context is associated with only one application" is also true); however, there is the possibility that a single machine may have multiple JVMs (or containers) running on it. In that case, since one JVM instance is isolated (at least in memory allocation) from another, there must be a separate context in each JVM. Hence the statement that "there is only one context per Web application", but clarified by "per JVM" in case there are multiple.

In a distributed application, you are working with multiple JVMs by design. Each server machine runs its own (software) server instance, and therefore each server machine has a separate JVM. Hence a distributed application requires that each application instance has its own context.

The spec. is not in contradiction with itself, but it needs to be read carefully.

I hope that helps!

[Reshma Shanbhag]

Answer to 1.) NO



Answer to 2.) & 3.)

'Distributed' means the application is clustered/ load balanced for giving better performance. This option is used to have high up time for the application with very high client traffic. In a cluster environment you have a group of servers servicing the client than an single instance of the server. For e.g. If one of the server in the cluster(group of servers in the same domain) is down the other server takes up the user request and processes the request, thats what i mean when i say high up time. I.E Even though the server to which the request landed initially crashed due to some reason the client request was handled by other sever ... hence the client request was handeled successfuly. The client is never aware of these details. The different instances of server in cluster group are communicative to each other about their states. for e.g when one of the server is crashing it would broadcast on a particular port (that it is crashing ) where all the servers in cluster group listen to .. so any of server which is comparitively idle would take up any request landing at the crashing server.


Scenario:
Consider a scenario you have server instances A and B in a cluster, a same web app (ex shopping site) is deployed on both the servers(so two instances of servlet Container). Each instance is in its own a JVM. Each instance (i.e A & B)has its own Servlet Context and each servlet deployed in them have their own ServletConfig. Only Session info is shared between the Instance A and B.

First time the user asks the app to add a book to the cart, the request ends at instance A, the session object is created and data is stored at A. Next time the user realizes he is not happy with the selected book so he requests the server to get the book out of the cart, as the server A is busy handling other customer's the request ends at Server B, the session information from JVM of server A is migrated into B (once session is migtared to B it is no longer exsist in server A) and the user request is handled. Only the session information is migrated not the Servlet Context or the Config.


I hope this was of some help to you


Regards
Reshma

[Charles Lyons]

Originally posted by Reshma Pai:
Answer to 1.) NO

Could you explain your reasoning for that? I have no less than four different applications running in one of my containers (servicing requests to different subdomains, different paths within a domain, and even entirely different domains).

[Reshma Shanbhag]

Charles i just read your post, i was wrong with the First question. I always thought each context root loads up in a different servlet container (hahah ).. Thanks for the details .. i am clear reading your post now.

What i got is. If two apps (ABC & CVB) are deployed in xyz.com domain they both load in the same servlet container and are identified because of their context root. Each instance of Tomcat is one instance of Servlet Container.

www.xyz.com/ABC and www.xyz.com/CVB

OK got it now .

Thanks Again,
Reshma
[ May 18, 2006: Message edited by: Reshma Pai ]

[Vivek Kinra]

posted by Reshma Pai:
Answer to 1.) NO

I am totally in agreement with Charles....

[Charles Lyons]

Actually, this is all a bit of a cloudy issue and probably depends on the server implementation used. For example, Tomcat defines the following in its internal API:

Container - an object that can execute requests received from a client, and return responses based on those requests

Engine - represents the entire Catalina servlet engine

Host (subclasses Container) - represents a virtual host in the Catalina servlet engine

Context - represents a servlet context, and therefore an individual web application, in the Catalina servlet engine


Now, I was considering the issue from the point of view that we only require one instance of Tomcat (which is a servlet container) in order to deploy several applications, even within different domains. But there is a different perspective...

Different domains running distinctly different applications will require a new virtual host (i.e. a new Host instance), and Tomcat isn't clear whether this uses a new 'container' (however that is defined) or not - one would assume it actually does, mainly because contexts and security (and single sign-on) only apply across applications in the same virtual host.

This is useful when you have two completely separate domains that utilise completely different applications, and allows them to use identical context roots for separate applications without causing conflicts.

Regardless, all virtual hosts (and therefore all applications) run inside the same Tomcat Servlet Engine instance used to process requests and handle servlet life cycles! But virtual hosts are isolated from each other in their use of file storage and context roots, so in effect are isolated completely despite running inside the same Tomcat instance and same servlet engine!

All very confusing...

You are correct when you say that context names don't include the domain name part... My example illustrated that it's possible to map several domain names into the same container (by aliasing the virtual host), but the context names for www.xyz.com/ABC and www.xyz.com/CVB would indeed be just /ABC and /CVB and not including the domain name. However, I could also alias sub.xyz.com to the same virtual host, which gives me sub.xyz.com/ABC as the same application (and we could also map xyz.com/ABC and www.xyz.co.uk/ABC to that same application).

In answer to the original question, if you're only using one virtual host (to avoid confusion here), it is still possible to use several different applications... This allows you to use other applications from other developers; for example, you might have an order management system, an administration console and a forum, all bought from different vendors. In that case, you can deploy each application separately and, for example, use context roots like:

"/" for the main application;
"/orders" for the order management;
"/admin" for the administration console;
"/forum" for the forum.

Each is its own application within your domain (or more generally, within a single virtual host). But no, applications (with different contexts but within the same virtual host) are all in the same container regardless of whether we consider different virtual hosts to be in the same container (which is doubtful). This allows us to use the ServletContext to obtain other ServletContexts for foreign applications, and therefore to use the RequestDispatcher (subject to security restrictions) between applications in the same container.

Whether it is possible to consider the mapping of different domains into different hosts as mappings "into the same container" (even though they are in the same Tomcat instance) is I suppose a bit debatable (on the precise meaning of "container") in Tomcat simply because of the way it shares resources and processes to maximise performance.
[ May 18, 2006: Message edited by: Charles Lyons ]

[Amit Das]

Hi all,

Well it was really gr8 to read the discussion....thanks to all.

But, still some confusion because of some text i read from Jignesh Malvia book for SCWCD, but 1st i'd quote what Charles replied for one of the questions......

Charles reply:

In general, J2EE Web servers (or just servlet containers like Tomcat) are built using Java... this means they are actually running inside their own JVM instance.

What Jignesh Malvia's book for SCWCD says (on page 7: Chapter 1, Understanding Servlets, Sec 1.2.2 Understanding servlet containers, In-process servlet containers).....

An example of this type (author is talking abt In-Proces servlet containers) is Tomact running inside Apache Web Server. Apache loads a JVM that runs Tomcat. In this case, the web server handles the static content by itself, and Tomcat handles the servlets and JSP pages.....

So is the author wrong in saying that Apache loads a JVM.....???

Thanks,
Amit

[Charles Lyons]

So is the author wrong in saying that Apache loads a JVM?

The author is correct... Apache is a (non-Java) Web server. In order to execute a Java Web server (in this case Tomcat), Apache has to start Tomcat, but Tomcat needs a JVM to run in (just like any other Java application). So Apache implicitly loads a new JVM as the first step towards starting Tomcat.

[Amit Das]

Cool Charles......
The time u've spent for answering is really appreciated...Thanks once again!!!

Ur explanation looks quiet mature and lucid to me......
I'm preparing for SCWCD with a goal of getting a good understanding of the server side. Would you mind if i ask u doubts personally???

Regards,
Amit

[Nikhilesh Fonseca]

I was under the impression that Session Migration is generally done when a server fails over and requests have to be transferred to a new server.
Is it also done just to handle excess traffic like transferring older sessions to a new server and just handling newer sessions.I thot the newer sessions would be transferred as in the first request itself would go to the other server in the cluster ??
Am I missing something here or is there a specification for this behavior..?

[Charles Lyons]

I was under the impression that Session Migration is generally done when a server fails over and requests have to be transferred to a new server.

I suppose so, but if a server fails (and/or the JVM crashes), there would probably be no way to retrieve that session information since it's most likely stored in memory at that point. Some sophisticated containers probably have such a fail-safe.

Is it also done just to handle excess traffic like transferring older sessions to a new server and just handling newer sessions.

Yes; a container will migrate a session in order to perform load balancing. I'm not sure what you mean by "transferring older sessions to a new server" however; there is only one session object used at any one time on one machine (otherwise there would be concurrency issues). So there isn't really any sense of an "old session".

I thot the newer sessions would be transferred as in the first request itself would go to the other server in the cluster ??
Am I missing something here or is there a specification for this behavior..?

Sorry, I don't actually understand what you mean in the first sentence; could you rephrase it?

As for specifications, check the Servlet specification, section SRC.7.7.2, "Distributed Environments" which glosses over the brief details of how and why migration occurs. It isn't extensive; much of the implementation is left to container providers.