tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Getting the Right High Availability Architecture for Tomcat
Date Mon, 11 May 2009 15:27:49 GMT
Nenad Kovacevic wrote:
> Caldarale, Charles R wrote:
>> Have you considered doing the SSL processing in the load balancer(s)?  It
>> would make life simpler.
>>  - Chuck
>>>From application's perspective it really does not make much of a difference
> where SSL is done - actually it does make now after your explanation -
> thanks for that - however this change would need to be run and approved by
> our networking and security people first. In any case I am afraid that even
> if they are willing to move SSL processing to the balancers this change may
> not happen in time for our first application, so we might end up with the
> setup as I described it in my original post. 
> Our applications do not issue concurrent requests to the servers, i.e. they
> are classical web applications where the user activates a control on a page
> and then waits for a page to refresh or a new page to load. Therefore under
> normal usage scenarios concurrent requests should really not happen. I say
> normal as it is possible for a user to resubmit a request by reloading a
> page using browser controls. However we warn the users to use only controls
> on the page and gray-out submit buttons once a request is submitted so
> hopefully this should not be an issue.
> With such an application in mind would you see an issue with not
> implementing sticky session? Again, I was able to test that and the only
> issue that I am seeing is that JSESSIONID changes depending on what Tomcat
> instance processed it, but again, I am not sure if that is really an issue
> or not?
Not sure if it is relevant here :
a browser will make (quasi-)concurrent requests to the server, for 
example when you load a html "frames" document.  The first request will 
be for the frames document itself, but as soon as that one is returned, 
each <frame> in it will be the object of a new request.
A similar case happens when a document merely contains <img> or <style> 
or <script> tags.  To "fill these slots", the browser will issue several 
requests (and probably establish several connections) in parallel.
I know that this kind of thing can play havoc with some authentication 
schemes for instance.  Again, I don't know if it is really a cause for 
concern in this situation.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message