Re: [wadi-dev] Re: [Geronimo] Clustering
these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. can you be more specific ? Jules James --- http://radio.weblogs.com/0112098/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net http://www.coredevelopers.net * * Open Source Training Support. **/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
Re: [wadi-dev] Re: [Geronimo] Clustering
should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto: dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code shouldliterally be a few lines. Clients using clusters should notsuddenly find themselves sucking down e.g. the whole of activemq,just to do a once off autodiscovery. Early versions of WADI had itsown autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API.Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response.Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. can you be more specific ? Jules James --- http://radio.weblogs.com/0112098/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net http://www.coredevelopers.net * * Open Source Training Support. **/--Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-systemcrystallises out around it./** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/ -- Ryan Thomas[EMAIL PROTECTED]
Re: [wadi-dev] Re: [Geronimo] Clustering
will need to talk to EJBs via OpenEJB's proprietary protocol and Trifork's IIOP impl (I'm not on my home ground here, so I might be off-base - but that is what the thread is for). HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill (JNDI will be small amounts of data that are write-seldom and read-often). One other issue that meshes with all of this is deployment. I've given some thought to clustered deployment recently and come to the conclusion that a deployment/app/?service? is simply a piece of write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may result in a number of entries being merged into HA-JNDI, an undeployment may result in a number being removed. If a new node joins a cluster (or subset of) that is responsible for providing an HA-service/app, then that node should deploy an instance of that app as it comes up and remove it as it goes down - i.e. a copy of that app should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto:dev@geronimo.apache.org mailto: dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code
Re: [wadi-dev] Re: [Geronimo] Clustering
- but that is what the thread is for). HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill (JNDI will be small amounts of data that are write-seldom and read-often). One other issue that meshes with all of this is deployment. I've given some thought to clustered deployment recently and come to the conclusion that a deployment/app/?service? is simply a piece of write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may result in a number of entries being merged into HA-JNDI, an undeployment may result in a number being removed. If a new node joins a cluster (or subset of) that is responsible for providing an HA-service/app, then that node should deploy an instance of that app as it comes up and remove it as it goes down - i.e. a copy of that app should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with.Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org mailto: wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto: dev@geronimo.apache.org mailto: dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code shouldliterally be a few lines. Clients using clusters should notsuddenly find themselves sucking down e.g. the whole of activemq,just to do a once off autodiscovery. Early versions of WADI had itsown autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that.??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. can you be more specific ? Jules James --- http://radio.weblogs.com/0112098/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net http://www.coredevelopers.net http://www.coredevelopers.net * * Open Source Training Support. **/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner
Re: [wadi-dev] Re: [Geronimo] Clustering
Rajith Attapattu wrote: Hmm, again we have stopped the discussion :). Lets get it started again. OK - I will pick it up. I've been a bit preoccupied with WADI for a while, so apologies for letting this one go cold. So can we all come to some agreement (with more discussion) on which direction we might be taking !! Like merging ActiveCluster and WADI or getting best of both worlds ? hmmm... not sure I follow you here... are you suggesting merging them because you view them as (a) competing or (b) complimentary technologies ? If (a), then I need to put you straight. WADI is a technology that builds on top of ActiveCluster (AC). AC provides basic clustering fn-ality (most importantly, a membership abstraction along with notifications of membership change). If (b), then, whilst WADI and AC could be merged, the current separation is along clear and modular lines and I see no advantage to collapsing the two projects into one. I think that there is far more reason to consider a merger between ActiveSpace (AS). AS is a project that also builds upon ActiveCluster to provide distributed caching fn-ality. The fundamental difference (and I stand open to correction from James here - I'm not very knowledgeable about AS) is that AS provides a host of optimistic caching strategies, whilst WADI (currently) provides a single, pessimistic strategy specifically designed for the management of state in web and ejb tiers, where the sum of the state in the tier is too great to be held by any single node. Because WADI and AC fulfil similar roles, I think that there is more to be gained by unifying their APIs and code-sharing between them. James, if you are reading, what do you think ? And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever) in terms of clustering would give folks like me more direction as to where we should concentrate on? Well, I think that there has been plenty of discussion, but you are correct in pointing out that there is no grand unified architecture document out there. I did start on my suggestions towards one quietly a while ago, but canned them. Perhaps enough discussion has now occurred to put up a straw man ? Is this what you are looking for ? If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo. Rajith, judging from our conversations on this list, your interest seems to lie in JNDI clustering ? I think that we need to get you, Gianny Damour (working on OpenEJB/WADI integration), James Strachan (ActiveSpace) and Kresten Krab (Trifork guy involved in IIOP stuff, which needs to be worked into equation) into a thread. OpenEJB will need cluster aware client-side proxies, delivered from HA-JNDI. These proxies will need to talk to EJBs via OpenEJB's proprietary protocol and Trifork's IIOP impl (I'm not on my home ground here, so I might be off-base - but that is what the thread is for). HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill (JNDI will be small amounts of data that are write-seldom and read-often). One other issue that meshes with all of this is deployment. I've given some thought to clustered deployment recently and come to the conclusion that a deployment/app/?service? is simply a piece of write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may result in a number of entries being merged into HA-JNDI, an undeployment may result in a number being removed. If a new node joins a cluster (or subset of) that is responsible for providing an HA-service/app, then that node should deploy an instance of that app as it comes up and remove it as it goes down - i.e. a copy of that app should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev
Re: [wadi-dev] Re: [Geronimo] Clustering
and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. can you be more specific ? Jules James --- http://radio.weblogs.com/0112098/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net http://www.coredevelopers.net * * Open Source Training Support. **/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
Re: [wadi-dev] Re: [Geronimo] Clustering
) into a thread. OpenEJB will need cluster aware client-side proxies, delivered from HA-JNDI. These proxies will need to talk to EJBs via OpenEJB's proprietary protocol and Trifork's IIOP impl (I'm not on my home ground here, so I might be off-base - but that is what the thread is for). HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill (JNDI will be small amounts of data that are write-seldom and read-often). One other issue that meshes with all of this is deployment. I've given some thought to clustered deployment recently and come to the conclusion that a deployment/app/?service? is simply a piece of write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may result in a number of entries being merged into HA-JNDI, an undeployment may result in a number being removed. If a new node joins a cluster (or subset of) that is responsible for providing an HA-service/app, then that node should deploy an instance of that app as it comes up and remove it as it goes down - i.e. a copy of that app should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org ; dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code shouldliterally be a few lines. Clients using clusters should notsuddenly find themselves sucking down e.g. the whole of activemq,just to do a once off autodiscovery. Early versions of WADI had itsown autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API.Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. can you be more specific ? Jules James --- http://radio.weblogs.com/0112098/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net http://www.coredevelopers.net * * Open Source Training Support. **/--Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-systemcrystallises out around it./*** Jules Gosnell* Partner* Core Developers Network (Europe) **www.coredevelopers.net** Open Source Training Support.**/
Re: [wadi-dev] Re: [Geronimo] Clustering
Hmm, again we have stopped the discussion :). Lets get it started again. So can we all come to some agreement (with more discussion)on which direction we might be taking !! Like merging ActiveCluster and WADI or getting best of both worlds ? And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever)in terms of clustering would give folks like me more direction as to where we should concentrate on? If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo. Regards, Rajith Attapattu. On 1/5/06, Rajith Attapattu [EMAIL PROTECTED] wrote: -Original Message-From: Jules Gosnell [mailto: [EMAIL PROTECTED]]Sent: Monday, December 19, 2005 9:55 AMTo: [EMAIL PROTECTED]Cc: wadi-dev@incubator.apache.org ; dev@geronimo.apache.orgSubject: Re: [wadi-dev] Re: [Geronimo] ClusteringJames Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code shouldliterally be a few lines. Clients using clusters should notsuddenly find themselves sucking down e.g. the whole of activemq,just to do a once off autodiscovery. Early versions of WADI had itsown autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formedresponse. Sure - an *implementation* of ActiveCluster API could do exactly that. ???well, maybe I'm thinking of the wrong piece of activecluster then ?any piece of code could broadcast a packet... which piece ofactivecluster's API are you suggesting here ?we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster.can you be more specific ?Jules James --- http://radio.weblogs.com/0112098/-- Open Source is a self-assembling organism. You dangle a piece ofstring into a super-saturated solution and a whole operating-systemcrystallises out around it./** * Jules Gosnell* Partner* Core Developers Network (Europe)**www.coredevelopers.net** Open Source Training Support.**/
Re: [wadi-dev] Re: [Geronimo] Clustering
James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. can you be more specific ? Jules James --- http://radio.weblogs.com/0112098/ -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
Re: [wadi-dev] Re: [Geronimo] Clustering
On 19 Dec 2005, at 14:54, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? You said... but simply a way of locating the cluster and requesting a membership snapshot of it. The entire purpose of the ActiveCluster APi is to locate members in clusters be informed when they go down. There's a zillion ways of implementing this - AC just tries to be a common, simple API we can share. we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. AC can be used purely to discover nodes and choose which one to use as a server. The local in-JVM node does not actually have to actually advertise itself to members of the cluster if it doesn't wish to - thats an implementation detail. (e.g. if you only want servers to be discoverable but keep clients invisible). Using the EJB client and server side example - you may want to know which clients are connected to what servers so that you can load balance; so even though you may not consider clients as 'members of the server cluster' being able to know who is connected to who is quite useful. EJB clients could expose statistics that can be used to help choose the right server a new node should join. But whatever - if you don't wanna use the AC API its no big deal; use whatever abstraction you see fit - I just wanted to explain the point of AC; for discovering nodes in a cluster and being able to choose which one to communicate with; it can be implemented any way you like (simple multicast stuff, using HTTP, LDAP stuff etc). Maybe it'd help if we separated AC into the 'messaging' part and the 'discovery' part? James --- http://radio.weblogs.com/0112098/
Re: [wadi-dev] Re: [Geronimo] Clustering
James Strachan wrote: On 19 Dec 2005, at 14:54, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of ActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well-formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? You said... but simply a way of locating the cluster and requesting a membership snapshot of it. The entire purpose of the ActiveCluster APi is to locate members in clusters be informed when they go down. There's a zillion ways of implementing this - AC just tries to be a common, simple API we can share. Sure we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. AC can be used purely to discover nodes and choose which one to use as a server. The local in-JVM node does not actually have to actually advertise itself to members of the cluster if it doesn't wish to - thats an implementation detail. (e.g. if you only want servers to be discoverable but keep clients invisible). OK - I see - but I'm not sure that I am drawn to this approach :-) Using the EJB client and server side example - you may want to know which clients are connected to what servers so that you can load balance; so even though you may not consider clients as 'members of the server cluster' being able to know who is connected to who is quite useful. EJB clients could expose statistics that can be used to help choose the right server a new node should join. understood. But whatever - if you don't wanna use the AC API its no big deal; use whatever abstraction you see fit - I just wanted to explain the point of AC; for discovering nodes in a cluster and being able to choose which one to communicate with; it can be implemented any way you like (simple multicast stuff, using HTTP, LDAP stuff etc). Its not that I don't want to use AC client side - its that I don't see clients as being members of the cluster in any way - passive or active. but, I guess this opens up an interesting topic... I'm thinking in terms of relatively large numbers of clients to servers. I wasn't thinking in terms of clients receiving any notifications about changes in cluster membership or state location. This is probably because WADI comes from a background in which the client is completely dumb, but also because a server may support many thousands of clients. I see the overhead of trying to pessimistically keep these clients in sync with developments within the cluster as outweighing the benefit. The architecture that I have in mind is more optimistic. It waits for something exceptional to happen - e.g. some state migrating as its node shuts down followed by a client for that state trying to make a call to it - then pays a small but exceptional cost in terms of a fail-over (which may become an autodiscovery in the even more exceptional case that all nodes in the cluster have been cycled between successive calls from the client). Thus, in the usecase that I expect, I think that the optimistic approach will be more efficient than the more pessimistic. However you should expect the unexpected - right :-) I guess that this way of thinking has prevented me from seeing clients as cluster members when perhaps they might be seen that way ? Perhaps we could look at how AC impls auto discover cluster members, then
Re: [wadi-dev] Re: [Geronimo] Clustering
On 19 Dec 2005, at 17:25, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 14:54, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation ofActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well- formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? You said... but simply a way of locating the cluster and requesting a membership snapshot of it. The entire purpose of the ActiveCluster APi is to locate members in clusters be informed when they go down. There's a zillion ways of implementing this - AC just tries to be a common, simple API we can share. Sure we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. AC can be used purely to discover nodes and choose which one to use as a server. The local in-JVM node does not actually have to actually advertise itself to members of the cluster if it doesn't wish to - thats an implementation detail. (e.g. if you only want servers to be discoverable but keep clients invisible). OK - I see - but I'm not sure that I am drawn to this approach :-) Why? Using the EJB client and server side example - you may want to know which clients are connected to what servers so that you can load balance; so even though you may not consider clients as 'members of the server cluster' being able to know who is connected to who is quite useful. EJB clients could expose statistics that can be used to help choose the right server a new node should join. understood. But whatever - if you don't wanna use the AC API its no big deal; use whatever abstraction you see fit - I just wanted to explain the point of AC; for discovering nodes in a cluster and being able to choose which one to communicate with; it can be implemented any way you like (simple multicast stuff, using HTTP, LDAP stuff etc). Its not that I don't want to use AC client side - its that I don't see clients as being members of the cluster in any way - passive or active. but, I guess this opens up an interesting topic... I'm thinking in terms of relatively large numbers of clients to servers. I wasn't thinking in terms of clients receiving any notifications about changes in cluster membership or state location. This is probably because WADI comes from a background in which the client is completely dumb, but also because a server may support many thousands of clients. I see the overhead of trying to pessimistically keep these clients in sync with developments within the cluster as outweighing the benefit. Who said anything about state synchronization? We're talking discovery here. The architecture that I have in mind is more optimistic. It waits for something exceptional to happen - e.g. some state migrating as its node shuts down followed by a client for that state trying to make a call to it - then pays a small but exceptional cost in terms of a fail-over (which may become an autodiscovery in the even more exceptional case that all nodes in the cluster have been cycled between successive calls from the client). Thus, in the usecase that I expect, I think that the optimistic approach will be more efficient than the more pessimistic. However you should expect the unexpected - right :-) I guess that this
Re: [wadi-dev] Re: [Geronimo] Clustering
James Strachan wrote: On 19 Dec 2005, at 17:25, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 14:54, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 14:14, Jules Gosnell wrote: James Strachan wrote: On 19 Dec 2005, at 11:53, Jules Gosnell wrote: , whether there is other suitable Geronimo or ASF-licensed code available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code should literally be a few lines. Clients using clusters should not suddenly find themselves sucking down e.g. the whole of activemq, just to do a once off autodiscovery. Early versions of WADI had its own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation ofActiveCluster which doesn't use ActiveMQ - its just a simple API. Sure - but I'm talking about the EJB-client side - where we just want to throw across as thin a line as possible, in order to haul a decent strength cable back. An EJB client would not need the ActiveCluster API (I'm not thinking in terms of making EJB clients fully fledged cluster members), but simply a way of locating the cluster and requesting a membership snapshot of it. Thats exactly what the ActiveCluster API is for :). Though by all means come up with another API if you can think of a better way of doing it. This could be done by just broadcasting a query packet at a well known multicast address and waiting for the first well- formed response. Sure - an *implementation* of ActiveCluster API could do exactly that. ??? well, maybe I'm thinking of the wrong piece of activecluster then ? any piece of code could broadcast a packet... which piece of activecluster's API are you suggesting here ? You said... but simply a way of locating the cluster and requesting a membership snapshot of it. The entire purpose of the ActiveCluster APi is to locate members in clusters be informed when they go down. There's a zillion ways of implementing this - AC just tries to be a common, simple API we can share. Sure we really are talking about just a remoting proxy which needs to find, but not 'join' a cluster. AC can be used purely to discover nodes and choose which one to use as a server. The local in-JVM node does not actually have to actually advertise itself to members of the cluster if it doesn't wish to - thats an implementation detail. (e.g. if you only want servers to be discoverable but keep clients invisible). OK - I see - but I'm not sure that I am drawn to this approach :-) Why? Using the EJB client and server side example - you may want to know which clients are connected to what servers so that you can load balance; so even though you may not consider clients as 'members of the server cluster' being able to know who is connected to who is quite useful. EJB clients could expose statistics that can be used to help choose the right server a new node should join. understood. But whatever - if you don't wanna use the AC API its no big deal; use whatever abstraction you see fit - I just wanted to explain the point of AC; for discovering nodes in a cluster and being able to choose which one to communicate with; it can be implemented any way you like (simple multicast stuff, using HTTP, LDAP stuff etc). Its not that I don't want to use AC client side - its that I don't see clients as being members of the cluster in any way - passive or active. but, I guess this opens up an interesting topic... I'm thinking in terms of relatively large numbers of clients to servers. I wasn't thinking in terms of clients receiving any notifications about changes in cluster membership or state location. This is probably because WADI comes from a background in which the client is completely dumb, but also because a server may support many thousands of clients. I see the overhead of trying to pessimistically keep these clients in sync with developments within the cluster as outweighing the benefit. Who said anything about state synchronization? We're talking discovery here. The architecture that I have in mind is more optimistic. It waits for something exceptional to happen - e.g. some state migrating as its node shuts down followed by a client for that state trying to make a call to it - then pays a small but exceptional cost in terms of a fail-over (which may become an autodiscovery in the even more exceptional case that all nodes in the cluster have been cycled between successive calls from the client). Thus, in the usecase that I expect, I think that the optimistic approach will be more efficient than the more pessimistic. However you should expect the
