Mika:
Thanks for the reply. Here's some more thoughts on this subject.
The primary problem that I see with the collaborative method
(e.g. extending the multicast solution) is
that all sessions will have to be sent to all cluster nodes. The
number session updates that have to travel 'on the wire' is in
relation to the number of nodes in the cluster.
Further more, when a new tomcat is brought on-line, it must
somehow retrieve a copy of all active sessions from somewhere.
There is nothing in place for this currently. Using multicast
is problematic. If a multicast request is made then all other nodes
would respond with all sessions. So, some other approach would
need to be taken which would result in two protocols being used
to make this feature work. This seems too complicated.
---------------------------------------
Consider this scenario:
A user establishes a session on node 1 (of a 10 node cluster),
Tomcat would create a new session and transmit it to the
multicast port, which would then transmit 10 copies of this
session (1 to each cluster node).
Now suppose that the next request from this user is sent to
node 2, which causes an update to the session to occur. Again
11 copies of the Session are transferred.
The number of session copies sent as the result of an update
is computed as follows: # of nodes + 1
node 1 sends new session to multicast port (kernel-level manager)
multicast port sends new session to node1
multicast port sends new session to node2
multicast port sends new session to node3
...
multicast port sends new session to node10
node 2 sends updated session to multicast port
multicast port sends new session to node1
multicast port sends new session to node2
multicast port sends new session to node3
...
multicast port sends new session to node10
node 3 .... 11 more session copies are sent...
NOTE: remember this is UDP traffic. The more packets that
fly around, the greater the likely-hood of dropping packets.
Dropped packets in this case means that some tomcat
instances may have stale (or no) data for a given session.
------------------------------------------
With a centralized session manager the following traffic would
occur instead:
node1 sends new session to server manager
node 2 requests the given (session id) session from the server manager
manager sends a copy of the session to node 2
node 2 updates the session and sends it back to the manager.
manager sends the 'invalidateSession(sessionId)' method in each of nodes.
(note: invalidateSession only contains the value of 'SessionId' + any
additional
RMI overhead. This is far smaller than a complete Session object)
The number of session copies sent as the result of an update is 2.
This number does not depend or vary based on the number of nodes.
Now, let's add to the story. Let's say that Tomcat is smart enough to cache
Session objects in it's memory space. Once Tomcat gets its hands on a
'Session'
it keeps it until it becomes 'too old' or an 'invalidateSession(sessionId)'
message is
received from the remote Session Manager. This could cut down the the number
of transfers of Session data from 2 to somewhere between 1 and 2.
-----------------------------------------------------
On Redundant Session Managers.
There are a couple ways to achieve this. One way is to place two Session
Managers
in the network. One of them is the 'active' one, the other one could simply
register itself
as a client of the 'active' server. As a client, it can obtain copies of all
new and changed
sessions from the active server. If for some reason the active server needs
to be brought
down, it will send a message to all of it's clients (including the 'dormant'
session manager)
indicating that it's shutting down. The clients could, on receipt of this
message, connect
to the 'next' session server (in their pre-configured list of servers). The
clients could simply
carry on with the new server.
If the active server simply goes off the air for some mysterious reason. The
clients would
get a RemoteException the next time they tried to talk to the server. This
would be their
clue to 'cut-over' to the other server (as described above).
Last point. Sending Session delta's instead of the entire Session:
This should be doable. The main thing that we care about are Session
attributes which
are changed by the application. It's up to the web-application to replace
these values into
the Session if their contents change. This is enough for us to be able to
track which attributes
have actually changed.
Tom
----- Original Message -----
From: "Mika Goeckel" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
<[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 3:14 PM
Subject: Re: Tomcat: Distributed Session Management revisited
| Hi,
|
| I'm looking at the same area at the moment. and try to get my head around
| it.... maybe we can help each other... further comments below.
|
| ----- Original Message -----
| From: "Tom Drake" <[EMAIL PROTECTED]>
| To: "Tomcat Dev List" <[EMAIL PROTECTED]>
| Sent: Monday, November 12, 2001 11:19 PM
| Subject: Fw: Tomcat: Distributed Session Management revisited
|
|
| > 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.
| >
| > 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.
| >
| > Regards,
| >
| > Tom Drake
| > Email: [EMAIL PROTECTED]
| >
| >
| > ----- Original Message -----
| > From: Tom Drake
| > To: [EMAIL PROTECTED]
| > Cc: [EMAIL PROTECTED]
| > Sent: Saturday, November 10, 2001 10:48 PM
| > Subject: Tomcat: Distributed Session Management revisited
| >
| >
| > Bip:
| >
| > I've looked closely at the existing catalina distributed session
| > management code, and determined that the following problems
| > exist. Since, I'm new to the code, it's highly likely that I've missed
| > something. Please correct any errors in my analysis, and provide
| > any input / feedback. I'm interested in contributing to this and would
| > greatly appreciate any input you can provide.
| >
| > Problems with current solution:
| >
| > - Session updates are not communicated to the other nodes in the cluster
|
| No, session updates are frequently communicated to all other cluster
members
| through the DistributedManager.run() method [processPersistenceChecks();].
| ... a second look came up with that only idle sessions and overflow
sessions
| are replicated...
|
| Anyway, that's a paradigm-thing... how accurate does a session need to be?
| After every change or just every couple of seconds. Should be
configurable.
|
| <...>
|
| I would vote for the cooperative approach, but I'd like to add some
| thoughts:
|
| Besides the primary session manager, there needs to be a backup session
| manager that captures the changes of sessions as well and is the crown
| prince of the primary session manager. This is to prevent sessions to be
| replicated to all other cluster instances (memory overhead) but to stay on
| the save side if the primary goes down (yep, both could crash, but what in
| live is 100%?). In that case the crown prince would take over and another
| cluster instance can take over the crown prince's role.
|
| Which server the primary manager is, should be either configurable or
| random. The cluster instances should be configurable. Multicast should
only
| be used if the cluster instances are not configured to find out what other
| instances are there. The configuration should only specify the initial
| state, further instances should be addable at any time without the need to
| bring the cluster down.
|
| Another thought is, do sessions need to be replicated in whole, or could
| there be a way to replicate only the changes (network overhead). I know
guys
| that store loads of things in sessions. We had a case where a whole search
| result (one complex object per row) was stored there, possibly up to a
| couple of megs...
|
| RMI would be my first approach as well, but I would try to keep the
| communication details separated from the functional logic implementing the
| cluster. This would enable us later on to choose other means like
JavaSpaces
| or JMS. RMI is the first choice if the cluster is near by, but what
against
| a cluster over a WAN if the requirements allow slow/deferred replication?
| RMI could not do that job reliable.
|
| Cheers, Mika
| ^X^C
|
|
| --
| To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
| For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
|
|
|
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
