On 12/11/2001 10:19 pm, "Tom Drake" <[EMAIL PROTECTED]> wrote:
> Tomcat Developers:
>
> This is a forward of a message that I sent to Bip and Craig a few days ago,
> regarding distributed session managment (aka Clustering). I haven't gotten
> any feedback just yet, so I thought I'd throw this out to the whole dev
> list.
This is always the wiser choice...
> The current implementation is broken. The following message explains
> why and describes some possible solutions to this problem.
>
> This feature (e.g. distributed session management) is an absolute
> requirement
> for any deployment that needs to scale beyond a single Tomcat instance, and
> does not want the overhead of depending on JDBC for storing sessions.
>
> I've also attached, at the bottom of this message, Two 'preliminary' RMI
> interfaces
> that describe (see scenario 1 below) how I think this session server and
> it's
> clients (e.g. tomcat instances) should converse.
> SessionServer - to be implemented by the remote session manager/server
> SessionClient - to be implemented by clients (e.g. Tomcat) of the remote
> session manager/server.
>
> I'm interested in making a contribution in this area and am anxious to
> receive
> some feedback from the dev-list members on this subject.
I looked down at the implementation, and so far I have two comments: the
first one is very stupid (AKA, package names :), but I'm concerned about one
thing: If we have a cluster of SessionClient(s), then sessions are stored
all on the SessionServer, and that introduces a single point of failure. I
mean, what happens if the SessionServer goes down?
AFAICS, all clients will loose their own sessions (unless sessions are
persisted to disk as in JDBC, and the server doesn't come back up in a
reasonable time)...
So, I'm wondering... Could it be possible to cluster also the server? Like
in NETBIOS networking, where each client is also server, and if the
"current" server (the one called "Primary Master") goes down, another one
takes on automagically...
Should go back and dig a little bit back on CIFS and how they do it at this
point...
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
