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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
