Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <013801bfe131$33d753a0$0101a8c0@matthew>
From: "Matthew Dornquast" <matthew@cata.com>
To: <tomcat-dev@jakarta.apache.org>
References: <Pine.GSO.4.21.0006271509390.20174-100000@costin.dnt.ro>
Subject: Re: Distributed Session Server
Date: Wed, 28 Jun 2000 13:46:42 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE>"IMHO the application have to deal ( and accept ) the possibility of
failure"

I agree 100%, I don't want to avoid the issue, I want to better isolate our
services in order to provide increased flexibility and uptime.  (And perhaps
performance?)

*** Imagine this environment:
A web application that has a 99.9% production uptime requirement and is
distributed across 10 web servers, 10 tomcats, 2 very reliable application
servers and one very reliable database.

The webservers have a redirector in front of them that reroutes http
requests to provide load balancing and auto recovery of failed http
requests.  The application server is distributed, and database has a 5
minute hot spare in standby.

Now for various configuration/production reasons, we need to restart tomcat.
Because session information is localized in the container, session state is
lost.

*** One possible solution
Okay now this gets subjective, and I'm really interested if you think this
doesn't make sense:

Move the session storage out of tomcat and into dedicated session server(s).
These servers sole purpose is to provide services that:

a)store session info
b)retrieve session info
c)distribute info amongst the collective farm of session servers.
d)migration of data from ram to persistent offline storage after certain
period of time.  (Nice to have, not critical)

In doing so I think I'll gain:
a)increased flexibility in maintaining front end web sites.
b)more transparent recovery if a web server/tomcat instance fails.

*** Kudos:
Obviously there is a cost when moving session storage "out of process" from
the tomcat vm perspective.  But I think if done correctly, it will come
close to mirroring the performance impact of sticky sessions, thus it'd be a
wash.

And as I said, I really like the default sticky session architecture.  I
think it solves 99.9% of the session storage requirements that are out there
today in a very elegant way.  I imagine the session server could be "drop
in" addition, similar to jikes for jsp.

-Matthew
PS> So the final env would be something like this:
2 redirectors
10 webservers with tomcat, configured in server.xml to use primary and
secondary session servers
2 session servers (primary, secondary)
1 application server
1 database
----- Original Message -----
From: <costin@eng.sun.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Tuesday, June 27, 2000 5:20 PM
Subject: Re: Distributed Session Server


> > While I like the "sticky session" feature built into tomcat,
> > it doesn't meet our needs production needs.
> >
> > (A tomcat server goes down, all sessions on that server are toast)
> >
> > So before I go out and write a distributed fault tolerant session
> > server for tomcat, is there already one that is started or in progress?
>
> Well, it will not be easy - partial "fault tolerant" may work, but you can
> never be sure that a session will be preserved.
>
> IMHO the application have to deal ( and accept ) the possiblity of
> failure. Session is a form of data repository/persistence, and I don't
> know any such a thing that can be 100% fault tolerant.
>
> It is better to design your application to deal with storage failures (
> by using transactions for example ). You just can't avoid that, and all
> session tricks ( saving in databases or files, sending UDP broadcasts or
> whatever else ) are just reducing the server performance without giving
> any real benefit ( since the data can still be lost - and your servlet
> will still fail because of that if it doesn't handle the error).
>
> When somebody finds a way to implement a 100% fault tolerant data
> repository, probably it would be a big day for databases and we can
> forget about transaction.
>
> Costin
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>