It sounds like you may have a misunderstanding of the interaction between your browser and a web server.
Let's just talk static content first. You request a URL for an html page; the server sends the page back to you. That's a request. Now if the html page you recieved contains 2 pictures then your browser will send off another 2 requests to the server to get those images. So that was 3 requests in total. Now stick a load balancer between your browser and the servers. All this will do is somehow allocate some requests to some webservers and some to others. How the load balancer does this is it's business, and the web servers don't care where the requests come from. Now let's think about a web application. In this case we have the idea of may sessions - but theses are just a way for the server & browser to logically group together a bunch of discrete requests. There is no concept of a session at the http level. The load balancer may or may not be session aware. To be aware of JSP sessions it needs to know that it should look for a "jsessionid" attribute in the requests and responses. If the loadbalancer is session aware & has 'sticky sessions' enabled then it will always route requests for a particular session to the web server where that session started. If sticky sessions are disabled then it will just send your requests to an arbitrrary web server. As you point out, the problem with using non sticky sessions is that session data has to be replicated to the other nodes in the cluster. This is often done when you call session.setAttribute() - the replication will happen then and there, or it may be done on a periodic basis. Due to this issue, and my relatively heavy use of session data, I've gone for a sticky session load balanced solution rather than a clustered solution. So, I can't tell you much more about the detail of session replication, other than it's container specific. Have a look at the mod_jk apache load blanacing ,odule for tomcat - http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html. Paul > -----Original Message----- > From: Woodchuck [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 14, 2004 2:37 PM > To: struts > Subject: load balancing and definition of a request > > > hihi all, > > there was another thread talking about load balancing / clustering and > session affinity so now i'm curious to understand more about this. > > given the following typical setup: > - one load balancing (dispatcher) server 'in front' of > everything and > receives all initial requests (LB) > - multiple app servers (servlet containers) 'behind' (A, B, C, D) > - one database server for all the app servers (DB) > > when someone enters a URL in a browser and submits it, this request > goes to the load balance server where it decides which app server to > use for this particular request. but that URL is typically an html > with other embedded resources like .jpg, .css, .js, .gif, and so on. > what really happens? > > #1: > the load balancer will go to A for .jpg, go to B for the .css, C for > the .gif, and D for processing the .jsp, and then put it all together > when these 'sub requests' are finished. > > #2: > the load balancer chooses one app server, say B, and then B is > responsible for all resource processing required for that URL/request. > > my questions are: > > is #1 possible? > > if #2 happens and henceforth all requests from the same session is > routed to app server B, is this session affinity? (is this aka sticky > sessions?) > > is it possible to have #2 happen, and then have subsequent requests > from the same session go to different app servers based on the 'most > available/idle' app server? (is this realistically achievable?... > after each request, the session would need to be copied/updated to all > the other app servers... what happens when this is not done > fast enough > before the session's next request?) > > > woodchuck > > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ********************************************************************** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
