Return-Path: 
 <tomcat-dev-return-20631-apmail-jakarta-tomcat-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org
Received: (qmail 18256 invoked by uid 500); 2 May 2001 16:59:01 -0000
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:tomcat-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:tomcat-dev@jakarta.apache.org>
Reply-To: tomcat-dev@jakarta.apache.org
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 14888 invoked from network); 2 May 2001 16:49:34 -0000
Message-ID: <3AF03A4D.7FBD44C2@openwave.com>
Date: Wed, 02 May 2001 09:48:13 -0700
From: "Mark.Abbott" <Mark.Abbott@openwave.com>
Organization: Openwave Systems Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [PROPOSAL Tomcat 4.x] Cluster
References: <3AEF9137.A4295A0E@razorfish.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

I would think that, if it already existed, the API described by
the new JSR 107 
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_107_cache.html
would be strongly considered as the basis for a distributed session
manager.  Any design made now ought to have an eye on going over to that
API in the future.  Perhaps that merely means that a new Manager
implementation could be made in the future.

This does not reflect either way on your suggestion for using MulticastSocket
and a Cluster abstraction. 

   Mark


Bip Thelin wrote:
> 
> I started looking at how to implement a DistributedManager and as I see it the
> best way to do this is to use MulticastSocket. So I started to look at how to
> implement it using MulticastSocket and started thinking about including that in
> a Cluster package. So you configure a <Cluster> package from within Server.xml
> The Cluster package joins a Cluster group(Multicast group) and have a defined
> set of methods/interfaces to communicate with each other. These clusters could
> then be used to implement in memory session replication, aka. Distributed sessions.
> 
> What we would gain from this in the future is that we can hook in different things
> that uses the Cluster, for doing weighted load balancing and other stuff.
> 
> I started writing some initial stubs and interfaces on how this could work, I
> don't just want to commit it without having ventilated it here first. Maybe
> this is a shitty idea to begin with.
> 
>         ..bip