Kief Morris wrote:
>
> [...]
>
> This is one possibility, but if this technique is used, I'm not sure there's
> a real need to distribute the sessions at all - the redirector can simply
> send the client to the Tomcat instance which holds the session locally.
Well that's true if the machine that originally held the sessions is still
alive, the beauty of ditributed sessions is that if the machine that spawned
the session unexpectadely died any server in the cluster could continue that
session.
> The problem I have with this approach is the front-end Tomcat becomes
> a single point of failure. A big advantage distributing sessions is that any
> Tomcat instance is able to handle requests for any client session, even
> in the event of failure of other instances. We should also allow Tomcat's
> distribution to work if a router-type solution is used to distribute incoming
> requests in a non-sticky manner.
Well I belive this is the way that the IBM network dispatcher works, and
you can cluster it so it would'nt become a singel point of failure. I believe
that we need some sort of frontend to the session distribution, I don't think
that we should allow a request to go to any server at any time in a cluster.
I think that we should as far as possible try to have the session in use hit
the machine that spawned it, we can't take for granted that any machine in the
cluster have an EXACTLY up to date version of the same session, there's always
gonna be some overhead in the replication procedure.
> I would make the (controversial, I know) suggestion that the domain
> for the cookie be configurable, so that organization foo.com can
> set cookies at .foo.com, which would be sent to Tomcat instances
> at www1.foo.com, www2.foo.com, etc.
This is what a dispatcher/frontend would do, but also keeps a list in memory
of where the sessions "belong".
> There have been a variety of suggestions for how to implement, including
> JavaSpaces, JMS, and JCache. Also JNDI and JDBC and the ugly old file
> system (if a networked file system is used) could work. MulticastSocket
> is a good idea I hadn't thought of - from looking at your code it's obviously
> workable and pretty straightforward. But I think we ought to make the
> mechanism pluggable the same way Store is pluggable for PersistentManager.
If we change name of the Cluster implementation to MulticastCluster it could
be pluggable by anything that implements the org.apache.catalina.Cluster interface.
We should also make a Interface to send and receive data that the
MulticastReceiver/Sender would implement. I'll start work on that immediately.
> We also need to answer the question of the request life cycle: the
> DistributedManager needs to know when a request begins and ends.
> At the beginning, it must lock the session to prevent other Catalina
> instances from using it in requests. This can probably just be done
> in Manager.findSession(). At the end, it must tell the ClusterStore to
> update the session to other members of the Cluster, and unlock it.
I'm not really sure what you're saying here. As I envisioned it a
DistributedManager is responsible for replicating sessions and to restore
replicated sessions. A Store is a pluggable component that are the
same for any Manager implementation(that makes use of a Store).
If we say that only one JVM at a time can manipulate a sessions since
a sessions only belongs to one machine at a time the only time a session
needs to be replicated is when it's created/changed/destroyed.
> A MulticastStoreCluster (or whatever) should be pretty straightforward
> to do with Bip's code. Some comments (intended as a "to think about/do",
> rather than as a criticism of Bip's code, which is meant as a starting point
> for discussion)
I'd rather see the replication be implemented in a Manager(i.e. DistributedManager or
maybe change name to MulticastDistributedManager) thus making it possible to
run any Store with the DistributedManager(i.e. FileStore).
Thanks for the comments Kief!
Regards, Bip
